L5 — Closure and verification · Stamped architecture

L5 owns the live card: assign a person, notify, track workflow, verify against L2 telemetry, close honestly, write ledger intents. It does not draft recommendations (L4) and is not the customer Forge UI (L6). In the architecture it is Layers 5 and 6 plus the AutonomyPolicy and the safety-filter owner (D15).

Label	Meaning
as-built	`closure-verification` (`stamped-l5`)
contract	prescription / card-proposal dual-read · workflow-event · ledger-entry (direction: Prescription, Action, ValueRecord, ClosureState)
direction	Full IPMVP bill M&V as product gate (ops clearance is the shipped verification path)

Repo#

Repo	Job	Must not
`closure-verification`	Ingest proposals → alarm → notify → workflow → clearance → ledger; internal console	L3 detectors; invent recommendations; override L4 withhold; `L2_DATABASE_URL`

Primary surfaces: FastAPI :8080 · worker tick · internal console :8095.

Pipeline (as-built)#

L5 pipeline

How to read it.

A proposal enters through ingest and passes the gates before it becomes a live card.
The card's code states are the 11 ClosureState values in stamped_l5_domain/cards/states.py (section 5.9); the workflow line above is the customer-visible path.
Clearance reads L2 tags; the ledger row is ops_confirmed, never bill-verified.

Build now: L5 /cards ingest of the L4 card proposal. Later: ValueRecord with status and tier (section 5.5).

View Mermaid source

flowchart TB
    %% house-style: l5-pipeline
    in["POST /v1/prescriptions/ingest"]
    subgraph card["Live card (as built)"]
        direction LR
        gate{{"gates / delivery judge<br/>(when stamped gate off)"}}
        al["alarm (when open)"]
        nt["notify: WhatsApp, SMS fallback"]
        wf["workflow: open → in_progress → done → verified"]
    end
    subgraph val["Verification and value"]
        direction LR
        clr["clearance poll on L2 tags (ops_clearance)"]
        led{{"ledger: potential → ops_confirmed realised"}}
    end
    own(["Owner acts in L6"])
    in --> gate --> al --> nt --> wf --> clr --> led
    own -.-> wf

    classDef govc fill:#fff4d6,stroke:#c99a2e,color:#000
    classDef agentc fill:#e8f0ff,stroke:#5b7bd5,color:#000
    classDef loopc fill:#eef7ee,stroke:#4f9a4f,color:#000
    class gate,led govc
    class own agentc

Evidence label	Meaning
`ops_confirmed`	Telemetry clearance passed — not DISCOM bill-verified (the `closed_verified` code value means this)
`bill_label`	Separate; default unverified until bill reconciliation matches

Customer L6 must hide staff-only statuses (withhold / pending review). Internal console sees them. Verified savings today: ₹0.

Messages, budgets and the Plant Box relay (direction)#

Not as-built. Decision: ADR-036 · one sender and budgets: D16, Plant Box local display: D7 · design: ../fast-loop/04-messages-budgets-and-missed-savings.md · ownership: ../fast-loop/07-interfaces-and-ownership.md section 6.

Item	Rule
`message_class`	`alert` (alarm rules) · `action` (a card or task for a person) · `signal` (a short cue inside an accepted standing procedure) · `digest`
Budgets	Actions 6–8 per person per day; signals at most 2 an hour per role; alerts follow alarm rules; digests scheduled
One budget per person	Cloud L5 is the budget authority. L4's `attention_budget` is a pre-filter on cards; anything that reaches a person counts against that person's L5 action budget
`stamped-l5-relay`	New Plant Box process (code in `closure-verification`). Reads `messages/out`, delivers signals and plant-local alerts, reports every send and reply to cloud L5. Offline: alerts and signals only, under conservative local caps; actions held; log reconciled on return
Procedure acceptance	A standing procedure is accepted once as a card by a named plant person, with its version; a new version needs a new acceptance. Per-shift switch: off from anywhere, on for writes only at the plant
Follow-through	Each action or signal gets an outcome from machine data (`ledger.follow_through`, produced by the twin); L5 links it to the thread via `episode_id`
Write log	L2 `ledger.write_log` is the record; L5 evidence holds references, not a copy
Staff console	New parts, candidate parameter rows, drift, settings (`require_internal_approval_new_part`), promotion history (`../fast-loop/06` section 7)

Autonomy today and how it is earned#

Policy: master document section 7; levels: architecture section 6. Today Stamped recommends and the plant team decides (AL1); every accept, edit, reject or defer is recorded.

Default: no autonomous actions. Two earned paths, both plant-approved, narrow at first, switchable off and recorded in an AutonomyPolicy (direction, section 5.6):

Staged setpoint writes through the Plant Box writer stamped-writer (ADR-035, D10, direction): stage 1 (AL1) messages only, stage 2 (AL2) a person confirms each write, stage 3 (AL3) an accepted procedure writes within limits per shift. L5 records acceptances and switches; it never sends writes.
Certified L5 classes: a class runs only after Stamped certifies it and a named plant owner enables it (first catalog: suppress a duplicate notification, open a review task). Idle-load and equipment actions are not in this catalog.

Safety systems, quality holds and release, maintenance authorisation and lockout, and customer priority, promise dates, routing, master data and the full dispatch sequence stay with the plant.

Layer handoff: ../../handoff/l5/stamped-l5-architecture-handoff.md
L4 proposals: ../l4/30-as-built.md
L6 experience: L6-experience.md

Repo#

Pipeline (as-built)#

Messages, budgets and the Plant Box relay (direction)#

Autonomy today and how it is earned#

Related#