Services
Three things we build: your state's eligibility layer, the bridge from the systems you already run, and the same treatment applied to any other body of legislation you have to get right.
State implementation
Your statutes, State Plan and amendments into a version-controlled corpus; your federal elections inventoried; your state layer authored on a proven pattern; and your policy authority signing off before anything reaches production.
Legacy integration on AWS
Your mainframe, eligibility system, portal and document store stay the systems of record. We build the translation layer between them and the rules — declared, gated and evidenced exactly like the rules themselves.
Any-legislation automation
Eligibility is where the method was proven, not what it is limited to. Any body of law that produces decisions can go through the same pipeline.
Legacy integration
The rules are not the integration.
What gets deployed is a stateless determination service. Your existing systems remain the systems of record, and they call us — inside your network boundary — with only the facts a single decision needs. Back comes the determination plus a decision report showing, provision by provision, which rule drove which conclusion. Nothing is retained.
That is only possible because the rule model holds no identifiers at all. The boundary is drawn once and it holds: personal data stays on your side. Facts cross per determination; determinations and reasons cross back.
Three shapes cover nearly every case
Real-time
A single determination from a caseworker screen or an online application. One call, one answer, with the reasoning attached.
Batch
A queued run for nightly redetermination or a mass change — the same rules, the same evidence, at volume.
Guided interview
An interview surface embedded in your own portal, driven by the rules themselves, so the questions asked are exactly the ones the determination needs.
Your fields, mapped to the model's inputs — under contract
The work between your systems and the rules is a translation problem, and we treat it as one more contract. The fields your systems actually hold are mapped to the model's declared inputs by a wrapper contract that names the source field, the target attribute, the transformation, and the read-back that proves it. Built the same way the rules are built: declared before it is built, gated, and evidenced.
| Job | Services |
|---|---|
| Synchronous transform and map — one decision, one call | API Gateway + Lambda |
| Orchestration and batch — nightly redetermination, multi-step flows | Step Functions + EventBridge |
| Bulk ETL and crosswalk tables — code sets, county maps, program lookups | S3 + Glue |
| Legacy database and SaaS sources | DMS + AppFlow |
| Observability, keys and access | CloudWatch + KMS/IAM |
That list is short on purpose
Every service on it is managed, boring, and — the property that actually matters here — deployable by contract: an agent can stand each one up, verify it against live state, and leave an evidence folder, the same way it authors a rule document. There is no bespoke middleware to write, nothing that needs a specialist to keep alive, and nothing whose behaviour we would have to describe to your assurance team from first principles.
A small, dull set is what makes the integration auditable rather than a second system to trust.
One line for the standards question, because it always comes up: attribute-level FHIR, X12 and NIEM mappings belong at the boundary, where data crosses — not inside the rules, where the law is the standard.
Any-legislation automation
If it is written in law and it produces decisions, it can go through this pipeline.
Eligibility was chosen as the proving ground because it is the hardest available case: the law is dense, the programs interact in ways nobody designed on purpose, and the cost of being wrong lands on a household. Nothing in the method depends on the subject matter.
What we bring to a new body of law
- The source pinned, cached and hashed, so the specification cannot move underneath the build.
- Authoring under contract, with a forbidden list as explicit as the required list.
- A machine gate that refuses anything red, and treats an absence of tests as a failure.
- Every reading the text did not state outright, escalated to a human and recorded.
- An evidence folder per change, with the plan written before the work.
- A generated dictionary that cannot drift from the model it describes.
Where it fits
Entitlements and benefits beyond the five families already encoded. Levies, charges and rebates. Licensing and permitting. Regulatory compliance obligations where an organisation must show why it reached a conclusion, not merely that it did.
The common thread is not the domain. It is the requirement to be able to defend an answer against the text that produced it — months or years later, to somebody who was not there.
How we work
The same discipline we apply to rules, applied to everything we deliver.
Declared before built
Scope, outputs, prohibitions and stop conditions are written down first. When a stop condition fires, work halts and a human decides — rather than an assumption being made quietly and discovered later.
Verified against live state
Verification reads the deployed reality, not the report describing it. A claim is not evidence until something independent has confirmed it.
Published whichever way it falls
Predictions go on the record before the build, and stay there whether or not they held. Our own defect list is published with dated deadlines. A project that cannot show you its defect list is asking you to trust its authors.