15. L3-L4 interface

L3 owns methods (detect, price, test, simulate, build verification plans). L4 consumes them as typed tools. L4 does not re-implement money, envelopes, or detector science.

---

1. Decision summary#

---

2. Why#

If L4 invents a parallel calculator, the card and the EvidenceLayer contract for detector output (direction; as built: Finding finding.json 1.2.0) record disagree on money. If L4 skips the condition test, discovery becomes storytelling. If envelopes are ignored, Modeled numbers read like Measured.

Split the work the way the plant already thinks: detection science and pricing methods in one place; “what should we do with this on this shift?” in another. Humans still accept the card.

---

3. Finding intake (L3 → L4)#

Floor (must hold before DecisionCase)#

Shadow means full trace and opportunity-ledger entry where applicable; nothing sent to L5 as a customer card.

What L4 may change on the Finding’s plan#

Verification plan on the card proposal may only narrow the FindingAs-built L3 detector output admitted to L4 (finding.json 1.2.0)’s plan (or the L3-built discovery plan): same measurement boundary, equal or tighter bounds, subset of allowed methods from the builder’s offer. Widening is a hard fail.

---

4. L3 methods port (tools L4 calls)#

All calls go through L3MethodsPort. Outputs are frozen into the evidence ledgerTyped rows (measured / advisory / model partitions) frozen into the trace (12-trace-and-eval.md). L4 cites method id + version; it does not re-implement these methods.

Calculator#

Sections are never summed into one hero ₹ across domains.

Condition test (discovery / hypothesis)#

Verification-plan builder#

Simulators (credibility envelope)#

Every simulator result carries an envelope. Emit may use the result only if inside envelope.

Also consumed when certified: system methods (bottleneck, blocked/starved, utility balance) and baselines for PSMPlant Situation Model history views.

L4’s l3_method_choice and simulate_vs_evidence seams select among registered methods; they do not author physics (11-models-and-seams.md).

---

5. Discovery hand-off#

L4 scanners / hypotheses
        │
        ▼
L3 condition test ──fail──► shadow + opportunity ledger
        │ pass
        ▼
L3 calculator (per section)
        │
        ▼
L3 verification-plan builder
        │
        ▼
L4 DecisionCase → same kernel as Findings

Certified patterns name their L3 method dependencies in the registry. Grounded-hypothesis laneOwner opt-in path for LLM hypotheses that still pass L3 grounding + dual-family + kernel also requires dual-family action agreement and plant owner opt-in (08-discovery.md).

---

6. Shared registry pack#

Both layers read versioned entries under stamped-external/registries/ (ADR-026; one registry D9, RECOMMENDED):

A new domain is declared once. L3 adds methods/detectors; L4 adds an analysis plug-in. Kernel and seams iterate by id — they do not hard-code the five names.

LockfileRelease pin of registry versions, kernel version, model pins skew between L3 and L4 releases is a failure mode: intake should refuse or shadow when required method versions are missing.

---

7. Pattern → detector retirement#

When L3 certifies a detector that covers an L4 discovery pattern’s condition keyStable id for “this plant condition”; one open card per key recipe:

1. Registry marks pattern retiring with deprecation window.
2. New emits prefer the Finding path.
3. After window, pattern retired; scanners may still feed Lab, not customer cards.
4. Trace links pattern_ref → detector_id for learning continuity.

Two active detectors for one condition is a bug, not a feature (08-discovery.md).

---

8. What L4 must not ask L3 to do#

• Override a hard constraint for modeled benefit
• Publish topology (site packVersioned, owner-reviewed plant configuration including topology / L1 path)
• Accept chat as a detector
• Sum section wallets
• Silently promote detector weights from L4 closures

---

9. Ownership summary#

Offline improvement may propose detector or pattern ideas for L3/L4 owners — it does not silently promote them (13-improvement.md).

---

10. Rejected alternatives#

---

11. Evidence that would change this#

• Envelope schema too coarse for Pilot 1 methods → extend fields; do not drop envelope checks.
• Condition tests too slow for shift sweepOnce-per-shift whole-plant discovery pass → cache typed results with as-known-at; do not skip the test.
• Registry skew incidents in staging → tighten release coupling or add explicit compatibility windows in the lockfile.

---

12. v1 slice vs later#

---

13. Fast loop and L4 (direction)#

Not as-built. Design: ../l3/05-twin-and-fast-loop.md · ../fast-loop/07-interfaces-and-ownership.md.

• Intake is unchanged. Twin outputs never reach L4 directly. Card-worthy twin conditions (procedure not followed, model drift, repeated part risk) arrive as ordinary 1.2.0 Findings from scheduled twin-record engines.
• episode_id. Such Findings list episode ids and the Plant BoxPlant-side computer for the fast loop (direction; D4) lockfile id in evidence references. L4 carries them into the case trace so a card links back to floor events; L4 zoom reads the twin records from L2 by episode (D3 twin on Plant Box, RECOMMENDED).
• Procedure explanation. L4 drafts the plain-words explanation shown on the L6 procedure acceptance card (what it watches, what it says, who receives it, its limits) from the versioned procedure YAML; it never edits the procedure.
• Procedure candidates. L4 may propose a new or revised standing procedure as a card from repeated cases or missed-savings patterns; it becomes live only through named plant acceptance of a new version (L5) and the stage gates in ADR-035.
• L4 never sends signals or WriteRequests; those stay on the Plant Box (section 5.8, direction).