Version. 0.1
Date. 2026-05-30
Status. Pre-scoping constraints note. Not a Change Request, not a scoping note — the orientation a scoping session opens from. Records the corrected scope (from two read-only inspections, 2026-05-29 / 2026-05-30) and the two Operator requirements the build must honour.
Author. Claude.ai. Operator: Marvin Percival.
Baseline. Engine main at daee809 (alembic head 0074, source identification merged).
The next step on the Memory-completion path is the credit gate over the pipeline — the mechanism that makes running the rooms cost something measured, so authorising many people against the pipeline does not mean uncapped spend. Two read-only inspections corrected the framing in ways that matter, and the Operator named two requirements that reach beyond the gate itself. This note records the corrected scope and the requirements so the scoping session starts from ground-truth, not from memory.
Three things to carry in: (1) it is three rooms, not four — Memory does not call a model; (2) the rooms have no metering surface at all today — no token capture, no system-key path, no spender threading — so the build constructs that surface, it does not extend an existing gate; (3) the Operator's two requirements (credits can later be sold at cost-plus; the credit system must have FORAY accountability) converge on one specific substrate gap the metering build should close while it is in the flow-writer anyway: there is no link from a consumption back to the grant that funded it, and the reservoir is an unbounded mirror rather than a funded source.
What the scoping session decides is in scope. This note does not decide it — it records what must be true.
Two read-only inspections grounded the framing against live code at daee809. The corrections:
It is three model-calling rooms, not four. Memory is a pure event-log write (events.py:118) — no model call, nothing to meter. Only Manifestation, Shaping, and Rendering call models. "Four-room credit gate" is a misnomer; this is the pipeline-spend gate over the three model-rooms.
The rooms have no metering surface today. This is the load-bearing correction. The earlier "extend the working gate across the rooms" framing was wrong in nature, not just degree:
complete() returns -> str — text only, no token usage. The rooms measure nothing. Metering requires changing the client contract to return usage alongside text, then threading that through every caller. Foundational and wide, not a surface tweak.get_api_key_plaintext). They have no system-key path and never touch the canonical three-tier resolver (api_keys/resolve.py — used today only by uploads). The credit system meters system-key spend; the rooms have no system-key spend to meter until this path exists.party_id = person_id). Manifestation is synchronous (the person is in the request). Shaping and Rendering run as async background jobs — and it is unconfirmed whether person_id is threaded into those jobs. If it is not, there is no spender to debit; this must be resolved before metering the async rooms.
What is mature and reused (not rebuilt). The ledger (credit.flows, append-only), the double-entry balance trigger, the tiered exhaustion gate with automatic tier-drop (opus → sonnet → haiku → exhausted), the async consumption recorder, the reconciliation and lifecycle evaluators, the two governing engagements (Credit Management …000048, Accounting …000049). The work is entirely the room-side surface plus adapting the gate to two execution models (inline for Manifestation, job-outcome for Shaping/Rendering).
complete() -> str to return text + token usage. Foundational; everything depends on it. Wide (every caller).resolve_engagement_api_key) rather than three divergent inline resolvers. Tidies real drift.person_id through the Shaping/Rendering async jobs. Prerequisite for metering the async rooms. Open question — verify first.complete() call. Adapt the writer to the one-call-per-room shape. This is where the two Operator requirements land — see §3.Dependency order: 1 first; 3 verified early (parallel); 2 and 4 build on those; 5 last.
Both reach beyond the gate. Both are settled requirements, not options.
Requirement A — credits-for-sale forward-compatibility. Loomworks (DUNIN7) will later let Operators purchase credits from the core reservoir at a cost-plus price — a revenue path beyond platform licensing, the same shape as promotional grants but priced and paid-for. Not built now; the metering build must not make it expensive to add. Implications the metering build must honour:
loomworks_credit_haiku/sonnet/opus) the room used — never a generic undifferentiated credit. Per-tier identity is what cost-plus pricing prices against. (Build piece 4 to write tier-identified flows, as converse already does.)Requirement B — FORAY accountability. The credit purchase-and-usage system must have FORAY accountability: every credit action (purchase, consumption) must be a FORAY-attestable transaction — actor, action, subject, authority, tier, quantity, timestamp — anchorable when FORAY integration opens. This is the product proving its own moat on its own infrastructure. Posture: build flows FORAY-attestable-complete and seam-marked now, even though anchoring is not yet wired — the same discipline source identification followed. Retrofitting attestability onto incomplete flows is expensive; building it complete is near-free.
The second inspection (FORAY posture of the credit code, daee809) found the credit flow path is seam-marked ahead of the turn path — _foray_reserved_emit is at all eight flow-writer sites (since Phase 63), no-op today. So the seam exists throughout. But "seam present" is not "attestable-complete." Three verified gaps, in priority order:
Gap 1 (the crux) — no grant→consumption lineage; only net balances. An issuance/grant flow knows its own grant_id. A consumption flow knows the work it paid for (turn_event_id ties spend to the causing turn) but not which grant it drew against — there is no column, no metadata, no draw-down/lot structure linking a spend to its funding event. So today you can prove total granted and total consumed per person per tier, and tie each consumption to its work, but you cannot attest which purchase funded which consumption.
This single gap breaks both requirements at the same link:
Both requirements are satisfied by the same fix: give consumption flows a grant linkage (which grant — or which lot, under a FIFO/draw-down structure — a spend draws against). This is cheap to build into piece 4 now (the consumption-flow writer is being built/adapted anyway) and expensive to retrofit onto flows written without it. This is the specific, bounded way the two requirements change the metering scope.
Gap 2 — the reservoir is an unbounded mirror, not a funded source. The balance trigger UPSERTs both sides of every flow, so the institutional dunin7 party's balance just goes more negative with each grant — there is no funding cap, no check that the reservoir "has" credits to issue (the gate checks only the person's positive balance, never the from-party). Fine for free promotional credits; insufficient for sold credits, where cost-plus margin and "provisioned vs sold vs consumed" reconciliation need a funded, accountable reservoir. Converges with Requirement A. Decide at scoping whether the funded-reservoir model is built with the metering work or deferred — but it is named here so it is a conscious decision, not a later surprise.
Gap 3 — thin seam payload; no content_hash. The _foray_reserved_emit payload passes only {flow_id, transaction_id, asset_id, quantity} — it drops the actor (from_party), counterparty (to_party), and subject (turn_event_id) the row carries. At FORAY-integration time the emit must widen to the full row shape. And no credit flow carries a content_hash/FORAY-native field. Both minor and deferrable, but recorded so they are not rediscovered.
Stated as one discipline, because all of the above reduces to it:
> Build the rooms' consumption flows FORAY-attestable-complete: tier-identified (never collapsed), linked to both the work they paid for (already present via turn_event_id) and the grant they drew against (the missing lineage — add it), against a coherently-accounted reservoir, with the seam payload widened to the full row shape. Reject every shortcut that collapses tiers, omits grant linkage, or records consumption without coherent reservoir accounting.
Get piece 4 right to this standard and both Operator requirements — credits-for-sale and FORAY accountability — are satisfied at the substrate level by the metering build itself. Credits-for-sale becomes "build the purchase mechanism on a ledger already shaped for it"; FORAY anchoring becomes "switch it on," not "re-architect the ledger."
person_id carried into the Shaping and Rendering async background jobs? Unconfirmed in inspection. If not, threading it is a prerequisite, not a detail. Verify before sizing the async-room metering.It does not scope the build (no REQ rows, no build steps), does not decide whether the funded-reservoir model lands with metering or later, and does not start the work. It records the corrected shape, the two requirements, the one convergent gap, and the constraint — so the scoping session opens on verified ground.
The model-tier asset map was also flagged stale in inspection (loomworks_credit_opus → claude-opus-4-7, behind the current opus-4-8) — a separate small follow-up, not part of this scope.
Version 0.1 (2026-05-30). Initial constraints note. Built from two read-only inspections at engine daee809: the credit-substrate / pipeline-spend inspection (2026-05-29) and the FORAY-posture inspection (2026-05-30). Records the corrected three-room scope, the five corrected pieces, the two Operator requirements (credits-for-sale, FORAY accountability), the convergent grant→consumption-lineage gap, and the single build constraint.
DUNIN7 — Done In Seven LLC — Miami, Florida Pipeline-Spend Credit Gate — Scoping Constraints Note — version 0.1 — 2026-05-30