What Adjust360 is¶
Authored by the expert, 2026-10-09
The layer it occupies¶
Claims systems record what happened. Adjust360 decides what the record supports. It sits beside the system of record, reads the facts a carrier has captured, and returns a determination per question: is there a subrogation theory, does coverage respond, who is at fault, what should the reserve be, who may authorise. Each determination carries the facts it read, the rules it evaluated, the facts it still needs, and the deadlines it could compute. Nothing is scored; everything is traced.
Two design rules follow the product everywhere. Facts, not conclusions: the intake carries what a document or a carrier said, and every conclusion is drawn later by a rule that cites its facts. Rules over facts, with no language model on the decision path: models may read documents into facts, and the harness asserts that zero model clients are constructed during a decision run.
What a tenant runs¶
Four runtime components ship to a carrier tenant, over two databases.
| Component | Who uses it | Reads |
|---|---|---|
| Pipeline and tools | The claim, through an API or the harness | The knowledge database |
| Claims Workbench | The adjuster | The claims database |
| Curation Studio | The carrier's curator | The knowledge database |
| Command-line utility (a360) | The platform team | Both, to configure, load, verify and observe |
The knowledge database holds only Adjust360 content: reference records (specs, theories, defenses, jurisdiction rules, sentence templates, glossaries) and platform knowledge chunks. The claims database holds processed claims and their traces. The base package is 3,009 documents, of which roughly 350 are read by a runtime tool during a decision and the rest are curation surface. No carrier's records ship in another carrier's bundle; the filter is by construction, and the verifier proves the absence.
The knowledge it reads¶
Three kinds of knowledge, each a governed record with a version, a curation status and an audit trail.
- Specs and corpus. Per line of business: which facts a tool reads and where in the payload they live (the input map), the theories with their requirement structures, the defenses with their class, the gates in their order. Changing any of these is a promotion through the recorded path, never a code change.
- Jurisdiction registry. All 51 states. Limitation periods, fault systems, subrogation sections, statutes of repose, anti-subrogation and immunity rules, each row with its cite, source URL, verbatim snippet, verification status and effective date. Curated by the testing team in a 13-field discipline and verified against primary sources; a domain opinion never overrides a verification.
- Rendering records. Sentence templates, field labels and the glossary. Every sentence on a brief comes from a template keyed by an outcome; no engine string ever reaches prose.
How a claim moves¶
A carrier payload arrives in the carrier-structured format (or a document arrives and is read into facts by the extractor). The normalizer validates it against the published schema and maps it to the canonical shape. The receipt mode reports, before any decision, what was stated, what was checked and found absent, and what was not supplied. Then the resolver serves the state's law, the detector screens structured indicators, and the module's rules tool evaluates gates, theories and defenses into a thesis record. The renderer turns the record into a brief, HTML and PDF, with a pointer from every paragraph back into the record. The full sequence, with the harness modes and the standing checks, is in How a claim runs. The normalizer itself has three layers: spec loading from the knowledge database, failing closed if a spec is missing; a vendor adapter that maps a vendor's output (Reducto, Databricks) or the carrier-structured format to the intermediate canonical shape; and canonical normalization, which injects not_returned for every spec-expected field the source said nothing about. The carrier-structured adapter is built and in carrier test; the Reducto adapter (EP-198) is not yet built. The boundary is specified in The intake boundary.
Lines of business and modules¶
| Module | Auto | Property | Workers' comp | General liability |
|---|---|---|---|---|
| Subrogation | In carrier test | In carrier test | Records seeded | Records seeded |
| Coverage | Built | Built | Built | Built |
| Liability | Built | Shares fault records with Auto; not run on the subro path | Built | |
| Obligations and deadlines | In carrier test | In carrier test | Built | Built |
| WC benefit rates | Built; New York schedule only | |||
| Compensability | Built, refactored | |||
| Reserve | Built | Built | Built (benefit schedules) | Built |
| Authority gate, complexity index, intelligence brief | Built, in the trace contract lineup |
"In carrier test" means the module has passed its evaluation kit on a held-out scenario library and is producing briefs for a carrier proof of concept. "Built" means the tool runs and has regression coverage; it joins the catalog as carrier-ready when it clears the same kit. The order of that lineup is set in the trace contract program.
What a carrier receives, and what never leaves¶
A carrier receives the format guide, the receipt, the brief, the thesis JSON, the glossary and, in a proof of concept, a scoring addendum. The intake schema is an interface, not intellectual property. Everything else stays inside: the corpus, the registry, the evaluator, the sentence templates, the seeds, the evaluation kit, the domain guide and every ruling.
Hosting¶
Carriers host the tenant in their own environment; ElevateNow's side is a release folder with a releasable flag, a code manifest and one install command. ElevateNow hosts its own workbenches and this site on Cloudflare, deployed from GitHub, behind access control.