Member Explanation of Benefits

The pairing matches each finished document to its driver record on the claimNumber key. This confirms the claimNumber values in the JSON driver file line up with the Application Product (the current legacy output the enterprise CCM system produces). Counts are real engine output from the driver-ingestion step.

The PII tokenizer runs over the real split statement text before any model call, replacing names, account numbers, addresses, and balances with typed tokens. Tokenizer: scaffold:acaas.onboarding.pii_tokenizer.PIITokenizer.

The Decision-Analyzer identified these zone candidates from the documents. These seed the zone candidates the design lead confirms in the wizard at the Content Zones step.

Each output datum the engine could trace to a driver-file field, with the inferred field mapping. The mapping itself is real engine output; the confidence is a keyless stand-in until the API key is set (see the LLM boundary above). The 0.7 threshold splits auto-confirm from the reviewer queue.

The bidirectional coverage check: hard exceptions are output data with no driver-file source (must be resolved before signoff); soft exceptions are driver-file fields that never render (dispositioned, not blocking).

Input fields never used on the page (soft exceptions): account_number, deductible_ind_limit, funding, has_denied_line, oop_ind_limit, oop_ind_met, provider_name, regulating_state, state_regulated. These are present in the driver file but the engine found no rendered output for them.

The structured-dialogue wizard runs against this ingested product. It presents the named steps that pertain to this product type, clustered by owning role, and holds every fact for explicit confirmation. ACaaS routes each gap by question kind (data, content, regulated); the enterprise authorizes who answers it through single sign-on, deny-by-default. Regulated content is confirmed by compliance.

A year of history has a horizon, so anything that runs less often than the learning window is not in the ingested history. ACaaS asks rather than waits to be told: it learned from 12 month(s), so it is likely to have missed anything that runs less often than that. What it captures here is a first-class runtime cycle on its own cadence, not a static note. Regulated cycles are confirmed by compliance.

A plain-language lane for what the structured questions do not cover. Free-form is a way in, not a raw override: anything you type is tokenized before any model reads it, interpreted into one or more concrete proposals you confirm, and written to the record and the audit trail like any other confirmed fact.

Once the gaps are resolved and confirmed, the wizard simulates a real output sample so you see what it will look like before committing. Only then is the product promoted, which is the handoff into the Console for review and the cutover gate. Promoting is not going live: ACaaS proves readiness and hands off, and the enterprise moves the asset to production against its own system of record, the ADF and its production stack.

This is the technical owner's lens on onboarding. It shows how each field of the delimited driver record decodes and binds into the learned regulatory skeleton, drawn field by field over the same coverage model this page already carries.

Connected mapping

The fixed-width escrow driver record decoded field by field, each field lined to the skeleton element it binds.

Open the connected mapping ›

Sectioned driver to skeleton

The same driver file grouped into sections, each section mapped to the RESPA skeleton region it populates.

Open the sectioned mapping ›

The working draft auto-saves continuously as you answer and confirm. You can name a checkpoint to return to, and each Promote cuts a locked, immutable revision with an incrementing rev number. Once a promoted revision is approved through the Console, self-serve promotion is disabled and a human owner handles further changes.

No named checkpoints yet. Create one to mark a point in the draft you can return to.

This action represents the Console approving the promoted revision. In the real system it happens in the Console after the handoff. Approving here locks self-serve promotion so the governance escalation is demonstrable.