Invoice Exception Reference System

Start with the complete worked engagement if you want to see why this boundary exists, what the economics would have to prove, and why the current evidence supports review-only shadow work rather than deployment. The runtime below is one slice of that engagement—not the whole customer outcome.

Objective

The optional document review lab adds an upstream source-to-draft exercise, live-model adapter and operator correction surface. It is intentionally disconnected from the posting tools below.

invoice exception event
  -> gather ledger/vendor/policy evidence
  -> propose resolution
  -> validate invariants
  -> authorize and stage
  -> approve exact proposal digest
  -> reauthorize and commit idempotently
  -> reconcile any effect-unknown timeout
  -> read back ledger state
  -> completed receipt | compensation + incident

Architecture

flowchart LR
    E["Exception event"] --> W["Durable workflow"]
    W --> R["Read tools"]
    R --> O["Invoice ontology"]
    O --> M["Resolution proposal"]
    M --> V["Schema + invariant validation"]
    V --> P["Policy decision point"]
    P --> S["Stage resolution"]
    S --> A["AP approver"]
    A --> C["Commit resolution"]
    C --> B["Ledger readback"]
    B --> Q["Effect receipt"]

Artifact map

Execute

npm test

Effect invariants

• resolution_commits(tenant_id, business_operation_id) <= 1
• runtime.release_digest == admitted_solution_release.digest before reads and effects
• commit.invoice_revision == current_invoice_revision
• commit.proposal_digest == approval.proposal_digest
• commit.policy_revision == current_policy_revision
• caller.tenant_id == invoice.tenant_id
• current_caller_scopes and current_policy_revision are checked at each data/effect boundary
• the data-context manifest separates operational, policy, evaluation, and telemetry uses and binds the agent's exact source projection, preparation, quality, output, and drift contract
• committed == true only after source-of-truth readback
• effect_unknown is reconciled before retry or completion
• completed == true only after trusted receipt and readback-attestation verification
• steps, wall_time, and cost stay within the declared runtime budget
• model_access(credentials) == false

Scope of the example

The worked engagement demonstrates how field evidence narrows a sold automatic-posting promise into a reviewer-controlled slice, then connects that decision to a value forecast, mechanism selection, controlled-write implementation, evaluation, adoption plan, handoff gap, and next-gate review. The runtime demonstrates exact release admission, contracts, current policy and identity checks, approval binding, duplicate-safe execution, effect-unknown recovery, signed service evidence, source-of-truth verification, runtime budgets, adversarial cases, and privacy-minimized trace evidence.

Every field source, role, value, and decision is a synthetic fixture. The solution release remains review, capability manifests remain candidate, signatures and registry records use non-production example identities, and evaluations run in an ordinary host process rather than an isolated production sandbox. The example does not claim authenticated production provenance, representative customer observation, customer adoption, realized business value, deployment approval, or completed handoff. Its evidence review keeps those gaps open.

Teaching-to-production boundary

The in-memory ledger, vendor master, policy service, tenant context, workflow state, receipts, and traces make the controlled-write contract inspectable; they are not substitutes for durable state, target identity and authorization, row- or field-level access controls, immutable or tamper-evident audit retention, concurrency control, migration, reconciliation, load, recovery, or restricted-environment promotion. Use Enterprise Integration and Scale Reality and the production service readiness record to replace each convenience with target-appropriate evidence. Do not translate this fixture line for line into a deployment.