What Adjust360 is

What it is

Adjust360 is a decision layer for claims. It takes the facts of a claim, reads the curated rules a carrier has approved, and returns determinations: whether a subrogation theory is confirmed, whether coverage responds, what deadline applies and from which anchor date. Every determination carries the facts it read, the rules it evaluated and the gaps it could not close.

The engines are rules over facts. A tool reads records, applies them and writes a trace. No language model is called on any rules path, and the harness asserts zero model client constructions per run for every rules tool . Where a model is used at all, it is on the document side, turning prose into facts with a citation, and that work is bought from extraction vendors rather than built as a product line. Extraction is treated as a commodity; interpretation and governance layered on top of it are the product .

The sentence that carries the positioning is: models read, rules decide.

The test that defines the boundary

The useful way to see what Adjust360 is, and where one tool ends and another begins, is to ask what remains in code once every rule, table and threshold has moved to records. What remains is an engine pattern: walk a spec's input_map and source_path, evaluate each record against the facts it names, write every evaluation to the trace, and refuse when a required record or fact is missing .

Applied to the reserve chapter, the test showed that vehicle valuation and statutory WC benefit schedules, which look unrelated, are one engine plus two record sets, while what looked like one tool (WC benefits) is two different questions, a statutory entitlement and a carried reserve. The same test is why no rule content, threshold, pattern list, state rule, default or fallback lives in code. A key a rule needs with no source path is a spec gap to report, never a flat default.

The corollary the arc kept relearning is that curation is the scarce input, not engine code. A rules engine with no rules is a well-tested null. Three tools were once classified shadow-ready on code completeness while their catalogues held no triggers, no narrative fields and no obligation records, so no claim in any state could compute a deadline. The remedy was one theory curated end to end before filling a catalogue.

Two personas, four components

Adjust360 ships as four runtime components, not two. The Claims Workbench points at the claims database and serves the adjuster. The Curation Studio points at the GKR database and serves the curator. The pipeline and tools run claims. A command-line utility configures, modifies and observes the tenant .

The adjuster reads outputs: the receipt returned before a run, the thesis brief, the thesis JSON. The curator maintains what the engines read: theories, defenses, gates, jurisdiction sections, sentence templates and the glossary, all as reference_data records with a lifecycle from draft to approved to active. Active is the platform's claim that a record was curated and regressed; it is an assertion about provenance, not a deployment flag.

The tenant split follows the personas. A clean GKR database holds only Adjust360 knowledge; a separate database holds processed claims. Of the 3,009 documents in the base data package, roughly 350 are read by a runtime tool during a claim decision and the remaining 2,659 are curation surface. That ratio is the shape of the product: most of what ships is knowledge for the curator to maintain, and a small governed subset drives each decision .

What the engines produce

The subrogation module is the reference case for the output shape. Input is a carrier-structured payload in the generated manifest format, every fact wrapped in a four-status envelope. Output is a two-layer thesis: a ten-field surface (referral with reason code and channel, primary theory with cited facts, other theories by status, gates and defenses, deadlines with status, preservation actions, two recovery figures, adverse exposure, verification items, a completeness ledger) plus the unabridged decision trace, with the payload hash, spec versions and ruleset hash in the header .

The richness of a brief comes from the trace shape, not the renderer. Any tool can produce an equivalent brief only once its trace carries cited facts with four statuses, every rule evaluated and recorded, indeterminates naming the fields they needed, money in heads and deadlines with anchors. That is the trace contract the program is now extending tool by tool .

Positioning against suite AI

Against the AI built into claims suites, Adjust360 sits at a different layer and makes a different kind of claim.

It returns determinations, not scores. There is no confidence percentage on a recovery; a theory is confirmed, indeterminate or excluded, and an indeterminate names the fact that would resolve it. Reserve and recovery are shown separately, never netted.

It is an unbundled decision layer on the carrier's own knowledge. The rules a carrier approves in the Curation Studio are the rules that run, and the layer is portable across claim systems. There is no data gravity move: structured claim data comes in through a published format, and the thesis goes back.

It is honest about gaps. A brief that cannot decide says so and names what was not supplied. The manual's bar is that a brief full of honest gaps passes and a confident brief with one fabrication does not.

Two things are conceded. Suites have workbench depth and cross-carrier benchmarks that Adjust360 does not claim. The honest comparison is one claim run side by side.

What a carrier does and does not receive

A carrier receives the format guide, the receipt, the brief in HTML and PDF, the thesis JSON, the glossary and the scoring addendum. The intake schema is an interface, not intellectual property. The domain guide, seeds, corpus, jurisdiction registry, evaluator, templates and evaluation kit never go to a carrier .

Open items

• The as-built inventory (docs/catalog/as_built_inventory.md plus JSON) that the catalog in product voice is to be written from has not yet been generated; its directive is to be issued after the Morales brief is accepted.
• Whether the tenant seed runs once at install or on every deploy, and who provisions the empty database and credentials, remain open with the deploy team.
• The loader refuses a non-empty target, so there is no upgrade path in place; changing the corpus today means a fresh database.