DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Record/Investigations/loomworks-boundaries-arc-cc-investigation-findings-v0_1.md
Status Current
Path investigations/loomworks-boundaries-arc-cc-investigation-findings-v0_1.md
←Back

Boundaries — CC Investigation Findings — v0_1

Version. 0.1 Date. 2026-08-19 Status. Discovery arc — read-only repo investigation, executed per loomworks-boundaries-arc-cc-investigation-brief-v0_1.md. Nothing was modified in any repository; this document is the sole output. Executed by. Claude Code (Fable 5), in the workspace holding the repositories. Operator: Marvin Percival. Method. Direct reads plus five parallel read-only exploration passes (one per brief section A–E); section F answered by direct reads. Every finding cites repo, file path, and line range. Findings without a citation are marked as guesses.

Repo header table — state at HEAD of main, 2026-08-19

| Repo | HEAD | Date | HEAD commit subject | |---|---|---|---| | foray | ad60eed | 2026-08-19 | docs: validation scope decision sheet v0.4 — R2 ruled PERMIT | | foray-api | 19d5a74 | 2026-08-19 | docs: carry-forward register v0.4 — CF-10 and CF-11 opened | | loomworks-engine | eb9392f | 2026-08-17 | CR-2026-225 post-merge: CI Postgres image gains pgvector | | loom | a3ef64e | 2026-04-15 | Initial commit: Loom Protocol repo scaffold | | grantha | 0292dcd | 2026-07-15 | grantha: ratification notice v0.2 — VERIFY-1 resolution folded in | | loomworks-record | b2721e0 | 2026-08-18 | FORAY audit coverage: FORAY's response filed; proposal v0.3 + request v0.3; build list v1.05 | | stele-agentic-id (supplementary, B6) | 4a87c1e | 2026-07-16 | V2 Cycle 5 — Revocation Enforced End-to-End | | stele (supplementary, B6) | 689de41 | 2026-07-18 | Release v0.4.0 — multi-origin ceremony support |

Scope note that governs all of Section A. /Users/dunin7/foray is the specification, governance-record, and public-site repo plus one narrow reference verifier. The producing/validating/anchoring implementation lives in the sibling repo /Users/dunin7/foray-api, which the spec repo names as the reference implementation (foray spec/FORAY_Verifier_Specification-v0_2.md:13; foray verifier/README.md:10). The brief said "the FORAY implementation in our repos" — answering A1–A6 honestly required reading both, and every citation below is labelled by repo. Additional sibling FORAY repos exist (foray-build, foray-kaspathon, foray-protocol, foray-protocol-db, foray-worker, dunin7-foray, dunin7-foray-validate) and were not investigated.

A. FORAY — implementation vs the published 4.2 protocol

A1. Which wire format version is actually emitted and validated today?

Direct answer: 4.2 — but the emitting/validating code lives in foray-api, not foray. 4.1/4.0 remain accepted through a permanent legacy-conversion arm.

Citations.

Elaboration. The WP-1 reference verifier in the foray repo does not know 4.2 exists — it is an anchor proof-bundle verifier (Merkle path, ABH, chain lookup), not a record validator; grep schema_version verifier/lib/*.mjs returns nothing. Drift flag: foray transaction-types/index.json:5 records "validator": "/api/validate-foray, foray-api v0.7.0" and every published transaction type as "validated_against": "foray-api v0.7.0" — a pre-4.2 validator (see Surprises).

A2. Is the governance column implemented — agent_activity_record with Arrangements/Accruals/Anticipations/Actions?

Direct answer: No — published-spec-and-exemplar only. No code in either repo knows agent_activity_record exists. This is partly by design: governance runs through the four standard components with zero special fields, so there is nothing type-specific to implement — and correspondingly nothing type-specific is implemented or enforced.

Citations.

Elaboration. The remaining work is named in the record itself: foray docs/decisions/foray-root-naming-ratification-decision-sheet-v1_1.md:96 lists "attestation code lists for F15 (crosswalk open item 6)" and a "general-audit coverage pass — verify the catalog expresses Stele/GRANTHA/Loomworks/OVA operational events in practice… sequenced after migration." F15's verdict code list is catalog-governed (docs/design/foray-root-data-set-v0_7.md:195) and the code list is not in the repo. For Boundaries: the wire can carry a governance record today, but nothing rejects a malformed one at the type level — a "governance record" is any record whose F26 happens to say so.

A3. Are registered streams implemented (monotonic seq, previous-hashes, CONTINUOUS/GAP/FORK walk)? Per-engagement / per-subsystem declaration?

**Direct answer: Partially — the continuity walk is implemented (verifier-side, consuming externally supplied history); the stream registry and producer-side stream encoding are not; stream scope (per-engagement / per-subsystem) has no vocabulary, schema field, or code anywhere — declaring one today is not implementable.**

Citations.

Elaboration. Do not conflate registered streams with batch-lane chaining, which IS built: foray-api lib/batch-accumulator.mjs:143-149 chains per-lane batch headers by windowId + prevHeaderHashHex — that is anchoring-layer chaining, and the amendment states explicitly it activates no stream machinery (…-v0_21.md:50 — "no new wire field, no ABH format change, and specifically no activation of stream_segments"). The governing decision sheet acknowledges the split: foray docs/decisions/foray-validation-scope-decision-sheet-v0_4.md:80 — registered streams are "something a consumer declares," the continuity walk is "auditor mode."

A4. Aggregation tiers for stream routing — code or spec-level?

**Direct answer: Partially — two-tier batch aggregation (per-client Tier-1 ABH beneath a Tier-2 aggregate) is fully implemented in foray-api, but dark and externally unreachable. Aggregation tiers for stream routing do not exist; the only routing rule is a spec-level rate gate for direct anchoring.**

Citations.

A5. The commit path — where would the Boundaries cop wire in, and does anything bypass it?

Direct answer: There is no validated commit path to bypass — the validator and the commit path have never been connected. FORAY's production ingestion route (POST /api/anchor in foray-api) commits opaque bytes with NO validation of any kind; POST /api/validate-foray is advisory and stateless. A cop would be a new gate, not a change to an existing one. The foray repo itself has zero write paths.

Citations — foray repo (zero write paths). Complete executable-file inventory (21 files): the WP-1 verifier is a read-only CLI (verifier/foray-verifier.mjs); scripts/ and tools/ write only site HTML/manifests; adapters/quickbooks-adapter.js and adapters/salesforce-adapter.js map to FORAY shape in memory and require('./foray-sdk') which does not exist in the repo (dead code, marked demonstration-only at quickbooks-adapter.js:6-10); web/legacy/ servers are retired. The deployed foray-site Worker has no code at all — wrangler.jsonc:26-31 serves site/ as static assets with no main script.

Citations — foray-api (the real path). Sole export default { fetch } route table at foray-worker-v0_19.js:2707-2754:

| Route | Handler | Validates? | Persists? | |---|---|---|---| | POST /api/generate-foray | handleGenerateForay (:998) | yes — on its own LLM output (:1190) | no | | POST /api/validate-foray | handleValidateForay (:1279) | yes (:1304) | no — returns a verdict and forgets | | POST /api/wp2-anchor-test | handleWp2AnchorTest (:2489) | no | signs + enqueues | | POST /api/anchor | handleAnchorPost (:2584) | no | KV put + sign + enqueue | | GET /api/anchor/<txHash> | handleAnchorGet (:2673) | n/a | read |

POST /api/anchor trace (foray-worker-v0_19.js:2584-2668): :2585 gate on ANCHOR_MODE !== 'on' → 404; :2588 authenticateAnchorConsumer — a single shared bearer token, constant-time compared (:2576-2582; per-consumer credentials an open item, :2568-2571); :2610-2616 size (1 MiB) and empty-body gates; :2618 the Worker computes SHA-256(body) itself; :2653 ANCHOR_BODY_STORE.put(txHashHex, bodyBuffer, { expirationTtl: 2592000 }) — the only durable record write; :2655 → signAndEnqueueAnchor (:1337-1352) → ANCHOR_SIGNER DO /sign (:1479 enqueue). No schema check is invoked anywhere on the path. The body is opaque bytes (:2555-2557 — "stores the body in KV keyed by that hash"); a 1-byte non-JSON blob anchors identically to a conformant 4.2 record.

Where the cop wires in — one seam per path:

  1. Direct/unified path: between foray-worker-v0_19.js:2616 (gates complete) and the true commit boundary at :2653 (the KV put — the code's own point of no return: ":2649-2652 — a storage failure throws here… before anything is ever signed or enqueued"). A veto immediately before :2653 and before the parallel put at :2626 (the UNIFIED_ANCHOR_PATH === 'on' branch — a second, separate commit site inside the same handler) covers the whole direct path.
  2. Batched path: AnchorSigner.batchAdd (foray-worker-v0_19.js:1554), before acceptRecord (lib/batch-accumulator.mjs:54). batchAdd takes bodyHex as an opaque parameter (:1561) and never inspects it either.
  3. Tier 2: acceptClientHeader (lib/tier2-aggregator.mjs:264) consumes headers, not records — a record cop has nothing to say there.

Every entry point that can commit (exhaustive, tests excluded):

  1. POST /api/anchor → handleAnchorPost (:2584) — no validation; gated by ANCHOR_MODE.
  2. POST /api/anchor with UNIFIED_ANCHOR_PATH === 'on' → second branch at :2624-2647 with its own put at :2626. Unset in every environment today.
  3. POST /api/wp2-anchor-test (:2489) — no validation; gated by ANCHOR_MODE.
  4. DO POST /batch/add → batchAdd (:1554) — no validation; DO-internal, no external route (:1399-1401).
  5. DO POST /direct-unified (:1389) — reached only from (2).
  6. DO POST /sign (:1423-1436) — accepts a bare 32-byte hash; no record context exists by this point.
  7. DO configuration routes /custody/configure, /client/register-lane, /tier2/configure (:1392, :1401, :1404) — DO-state writes, not records.
  8. The batch alarm/timer cut path — cutBatch (lib/batch-accumulator.mjs:149) and cutAggregate (lib/tier2-aggregator.mjs:377), which since Brief 19/CF-4 also enqueue in the same serialized operation. A non-request-initiated commit path: a cop living only in fetch handlers does not cover it.
  9. Queue consumer → lib/batch-broadcast-job.mjs, broadcaster/ — downstream of commit.
  10. scripts/purge-anchor-job.mjs — operational removal of a queued job.
  11. POST /batch/sign-enqueue — REMOVED at v0.19 (:1383-1386) because "a second producer of anchor jobs is the shape that let CF-1 arise" — the closest existing artifact to the single-choke-point discipline this question asks about.

A6. Bounded commitments carrying a measure (approval ceiling in the amount field)?

Direct answer: Two readings, two answers. As "an approval ceiling in F7 on an authority-grant Arrangement": No — the wire can carry it, nothing defines or checks it, and F7 has no per-family measure semantics anywhere. As the COUNTED-SUB-COMMITMENT discipline: Yes — implemented, but it is about batch leaf counts, not approval ceilings.

Citations — reading 1 (not implemented).

Citations — reading 2 (implemented).

B. Loomworks — the engine state

B1. Credit spend-tier _AGENT_KINDS: shape, call sites, and does it still match "one limit type, blocking, in the commit path"?

Direct answer: Partially. One limit type — yes. Blocking — yes. In the commit path — NO, and there is no evidence it ever was: it gates the model-room spend path (LLM complete() calls), not the memory-commit path. What changed since CR-2026-098 v0_3: _AGENT_KINDS is no longer a local literal — CR-2026-120 Step 4 re-pointed it at the shared NON_HUMAN_ACTOR_KINDS constant, unifying vocabulary with the commit/discard gate while the two gates remain separate enforcement points on separate paths.

Citations. All paths under loomworks-engine.

Elaboration. One dimension only: a boolean per tier (person_spend_authorized, agent_spend_authorized) on credit.engagement_spend_authorization, both defaulting False with no row (authorization.py:43-68) — no rate limit, budget ceiling, or window (the tier-cascade at gate.py:101-109 is a balance check, not the authorization limit). The gate is a hard pre-spend stop (gate.py:1-27 docstring: "the PRIMARY, PRE-SPEND control for the three model-rooms"). The memory-commit path has a different, independent gate — the NON_HUMAN_ACTOR_KINDS human-authority check at engagement/assertions.py:284, engagement/creation.py:905/:959, api/deps.py:1250. The shared frozenset is the likely source of the "in the commit path" conflation. Design v0_2 should treat these as two chokepoints, not one.

B2. Boundary-record subsystem: schema, and is anything writing these records?

Direct answer: Yes — records are actively written today, rule is in fact the DEFAULT decider kind, and rule-kind records are read back downstream. Two production writer entry points exist.

Citations. All under loomworks-engine.

B3. CR-2026-128 (retract/revoke human-only gating): executed or drafted?

Direct answer: Yes — executed and landed, in three places, with test coverage.

Citations. All under loomworks-engine.

Elaboration. Retract now sits in the identical enforcement lane as commit (assertions.py:284) and discard (assertions.py:601) — three symmetric guards on one shared frozenset plus the shared HTTP dependency. Delegation revocation is gated behaviorally (propose→confirm) rather than type-level, since it flows through assertion retraction underneath.

B4. Does Loomworks emit any FORAY records today?

Direct answer: No. Every emission site calls a deliberately no-op function that writes a debug log line — without the payload — and returns. No local store, no HTTP client, no queue, no SDK dependency.

Citations. All under loomworks-engine.

Elaboration. Where records go: nowhere — they terminate in a debug logger. Naming hazard: CorrectiveForayFlow / CorrectiveForayFlowRenderSpecialist (credit/specialists.py:127-150, credit/proposal_applier.py:314-432, credit/bootstrap.py:332-370) are Loomworks-internal credit-reconciliation artifacts, not FORAY substrate records; the DB table was renamed foray_action_flows → flows (credit/models.py:11, :65).

B5. Any preflight/dry-run on any commit path?

Direct answer: No. Nothing on any commit path answers "would this succeed?" without committing. The two nearest analogues are not commit paths.

Citations. Searched preflight, dry_run, dry-run, simulate, validate_only, check_only, would_succeed, precheck, what_if, no_commit, rehearse, trial_run, plan_only across loomworks-engine/src.

Elaboration. Practical consequence: the human-authority gates (B3), the spend gate (B1), and the step-up gate (engagement/step_up_policy.py; creation.py:911) are discoverable only by attempting the action and catching the raise/403/402. Nothing composes them into an ahead-of-time verdict. The Boundaries preflight capability is greenfield.

B6. Actor identity for non-human actors — anything Stele-shaped?

Direct answer: Partially. Every action carries a frozen ActorRef with a kind discriminator — but there is no per-agent identity object, no persisted purpose field, and no freeze state in the engine. Agent identity is a ContributorRow with kind='agent' plus, in several cases, a hardcoded sentinel UUID constructed inline. A genuinely Stele-shaped per-agent lifecycle (revocation, reversible clamp) exists in the sibling repo stele-agentic-id — which nothing in the engine imports.

Citations. All under loomworks-engine unless noted.

C. Loom (protocol) — governed-object readiness

Layer note. The loom repo is an empty scaffold: HEAD a3ef64e is its single commit, containing 2 files (README + one working note, 239 lines total); specification/, reference-designs/, tests/ exist as empty untracked directories, and the commit message says the spec "was not available at initial commit time and will be added when located." The spec lives in loomworks-record/protocols/loom/Loom_Protocol_Specification_v0_1_2026-04-12.md (133 lines). The entire real implementation is inside loomworks-engine, which substantially exceeds the spec (extra transitions discard/redirect, a 14-term relationship vocabulary vs the spec's 6, a fourth assertion state). The engine is the de-facto spec.

C1. Can Loom hold a versioned tree-structured object with provenance, citable at version + node?

Direct answer: Partially — versioned + provenanced + permanently citable: yes, today, at whole-object granularity. Tree-structured: no. Limit trees would need a new assertion shape (or a new relationship term); the spec contains no notion of trees, hierarchy, or nodes.

Citations. All under loomworks-engine unless noted.

Elaboration — the two routes for limit trees, neither free. (1) Add a containment term to RelationshipVocabulary and build the tree as node-objects + relationship edges — lower friction, and the only route where existing version-pinned citation machinery works unchanged per node; but a spec-level addition, not just code. (2) A new MemoryObject subclass with a nested payload — mechanically easy (Seed, Finding, Channel, RuleSet all subclass), but the whole tree versions as one object and "version 7, node X" would need an intra-object path-addressing scheme that exists nowhere in the codebase. The node-citability requirement favours route 1.

C2. Amendment/correction lifecycle in code — propose → review → commit-as-new-version, or write-time only?

Direct answer: Yes and no — two different lifecycles exist. Assertions: write-time only (every transition writes a new version immediately; no proposal stage). Seeds: a genuine propose → review → commit ceremony exists, production-grade, and is the reusable template for a limit-tree amendment lifecycle.

Citations. All under loomworks-engine.

C3. Replay/testing tooling against historical state?

Direct answer: Yes — substantially more than partial. Both axes of time travel are implemented, tested, and used in production paths.

Citations. All under loomworks-engine.

Elaboration. For a limit tree whose nodes are MemoryObjects in the event log, "show me this tree as it stood at engagement version N" works today for free.

D. GRANTHA — authorization state

D1. What does GRANTHA actually govern in code today?

Direct answer: Nothing. Zero lines of executable GRANTHA exist anywhere. The grantha repo is 100% documents; the engine holds two comment-marked seams for a future GRANTHA plus two GRANTHA-shaped-but-not-GRANTHA enforcement columns.

Citations.

D2. Anything mandate-shaped — scoped, time-boxed, signed authority with expiry?

Direct answer: Partially — fully specified in doctrine, entirely absent from code. The live delegation grant is scoped-but-immortal, unsigned, and un-digested: the opposite of mandate-shaped on three of four axes.

Citations — code (no). loomworks-engine src/loomworks/delegation/schema.py:76-100 against the FORAY 4.2 authority-grant fields: principal/agent — absent as fields (implied by assertion placement); scope — present (engagement-id granularity); window/expiry — absent entirely (grep across delegation/*.py for expiry constructs: zero; a delegation lives until explicit revoke_delegation, delegation/service.py:105); signature — absent (AuthorizationResult, authorization.py:57-70, has four fields: authorized, delegation_ref, approval_mode, reason); artifact digest — absent (no hashing in the package).

Citations — doctrine (yes, precisely). grantha design/GRANTHA_GRANT_CHECK_CONTRACT-v0_2.md (2026-07-12, marked "Design draft, uncommitted"), §3 — the Grant-Check Assertion: GCA = sign_authorizer(capability_ref, principal_ref, audience, effective_scope, state_seq, issued_at, expires_at, nonce). Signed (quorum-held key, §6 item 4); dual expiry — wall-clock expires_at = issued_at + W plus a state_seq backstop (§3 "Replay bounds"); window W a per-grant attribute bounded by system ceiling W_max (§5.2, RECOMMENDED-INTERIM at §5.3); capability_ref opaque ≥64 bytes (A4 floor, ratified cb88884); requested_scope grammar [DEFERRED] (§2) — gated on the §4.1 fork which was subsequently dissolved by the ZK drop (see Surprises); fail-closed §7 ("Nothing extends past expires_at. No stale-serve, no fail-open"). Artifact digest lives not in the GCA but in the anchoring envelope's commitment: "H(event_body)". The clamp guarantee T + P + W + S (§5.1) is the mandate-expiry theorem. None of it is built.

D3. Does a GRANTHA grant emit or reference a FORAY Arrangement anywhere?

Direct answer: No — in code, zero coupling in either direction. In doctrine, also no — and that is a deliberate, reasoned refusal, not an omission: GRANTHA's ruled position rejects the Arrangement mapping in favour of a uniform blinded envelope, and even that adoption is still OPEN/unruled.

Citations.

E. OVA

E1. What is OVA?

Direct answer: OVA is a decentralized, privacy-preserving access-control protocol — a yes/no authorizer specified as a based-ZK application on the Kaspa blockDAG. It is a specification project, not a codebase: no OVA implementation repo exists anywhere on this machine. The only running OVA-labelled code is a stub behind a seam inside loomworks-engine (CR-2026-157, "OVA Slice 1"), which is Loomworks's own authorizer, explicitly not OVA.

Plain English. OVA decides who may do what without letting anyone watching the network learn anything about the decision, the requester, or the shape of the permission system. Permissions live in on-chain objects called eggs; decoys (chaff and pooled nest eggs) are serialized byte-identical to real ones, so a full-chain observer cannot tell them apart without the key. A requester submits a zero-knowledge proof that they satisfy the access rules without revealing which rule or who they are; each authorization hop fans out to N addresses, only one real, hiding the permission graph's topology. OVA answers granted/rejected and nothing else — it does not hold the protected data, does not know whether the requester is human or agent, and depends on no identity system.

Citations.

E2. Does OVA overlap Boundaries Plane 1, Plane 2, the Stele, or the perception layer?

**Direct answer: No on all four — and on identity the non-overlap is a named design commitment, not an accident. The real collision risk is not OVA-the-protocol but the two OVA seams already inside loomworks-engine, which own the "may this actor do this action" chokepoint that a Plane 2 design would otherwise duplicate.**

Per concern, with citations.

E3. Does OVA consume or emit FORAY records?

Direct answer: Emit only, never consume — per spec (FORAY v4.1, REQ-051–058). But finding F-4 has ruled that emission wrong-layer, downgrading it to an optional off-by-default facility and removing REQ-055/058 outright — a spec pass not yet executed, so V3_2 still carries the obsolete rows. Separately, the shipped Loomworks OVA Slice 1 code registers three FORAY-anchored events — decision-level, i.e. already following the F-4 pattern — which today terminate in the B4 no-op emitter.

Citations.

F. Seed and record

F1. Highest-numbered candidate seed at candidate-seeds/loomworks/?

Direct answer: v0_14.

Citations. loomworks-record candidate-seeds/loomworks/ contains loomworks-candidate-seed-v0_14.md + .html (committed 2026-08-06, 6f0a905 — "seed v0.14 — GRANTHA and OVA named by placement, not function"), alongside loomworks-candidate-seed-v0_14-amendment-v0_1.md (the v0.13→v0.14 amendment instruction sheet) and loomworks-candidate-seed-v0_13-amendment-v0_1.md; archive/ holds v0_8 through v0_13.

F2. Do the seed's identity/authentication commitments constrain or conflict with the Stele as designed (solution design v0_2 §6)?

**Direct answer: Partially answerable — the comparison could not be completed, because solution design v0_2 is not present anywhere in this workspace (see F3/Surprises). What CAN be stated from the seed: its identity commitments are about human users and do not on their face forbid a separate agent-identity object, but they impose three constraints any Stele design must satisfy, and the seed's own discipline constrains how the Stele may be written into the seed.**

The seed's commitments, quoted. loomworks-record candidate-seeds/loomworks/loomworks-candidate-seed-v0_14.md:

Constraints on the Stele that follow. (1) If agents get identity objects, references from Loomworks records, FORAY attestation, and GRANTHA authorization must run against a UUID-class cryptographic identifier, not names or channels — line 119's pattern generalizes and the engine already conforms (ActorRef.id: UUID, B6). (2) No communication-attribute may ever function as agent identity or recovery. (3) The seed-discipline constraint: v0.14 exists precisely because v0.13 wrote another protocol's mechanisms into the seed — "the seed's own stated discipline is to commit postures and defer mechanisms" (loomworks-candidate-seed-v0_14-amendment-v0_1.md:15-23), and "a seed that names only the seat cannot go stale when the occupant's internals change" (:29). If the Stele enters the seed at all, it enters as a named seat, not as identity-object/purpose-field/freeze-state mechanics. Note the seed nowhere mentions the Stele today (grep for "stele" in v0_14: zero hits).

Not verified (and marked as such): whether solution design v0_2 §6 as drafted conflicts with any of this — the document is not in loomworks-record, not in ~/Downloads, and not anywhere findable in this workspace. Any claim about §6's content would be a guess; none is made.

F3. Does the record contain Boundaries-arc documents beyond the five produced 2026-07-06?

Direct answer: No — nothing newer. And a stronger fact the question didn't anticipate: only ONE of the five arc documents is in the record at all.

Citations. The record holds investigations/loomworks-boundaries-arc-opening-thesis-v0_1.md (+ .html), committed 2026-07-02 as b978326 ("Add discovery arc opening thesis: boundaries as operational primitive v0.1"). git log --all --since=2026-07-01 filtered for boundary-named files shows no arc documents after that; a filename sweep for boundaries-arc outside record-site/ mirrors returns only the opening thesis. The two-plane architecture, research, solution design v0_2, and build path documents are absent from loomworks-record, from ~/Downloads, and from every location searched. The Downloads bundle loomworks-boundaries-docs-2026-07-06.zip contains the CR-098/CR-128 engine-boundary documents (inventory, inspection findings, enforcement plan, standing notes) — a related but distinct body of work, all of it already in the record. BOUNDARIES_LOCATOR_PULL-v0_1.zip (2026-07-12) contains only the opening thesis plus FORAY references.

Surprises

Things the questions didn't anticipate, gathered rather than woven in. Grouped by area; each carries its citation above or inline.

Arc record integrity

  1. Four of the five Boundaries-arc documents are not in the record — or anywhere in this workspace. Only the opening thesis landed (2026-07-02, b978326). The two-plane architecture, research, solution design v0_2, and build path exist, as far as this workspace shows, only in the chat session. The arc's design authority currently has no committed home. (F3.)

FORAY

  1. /Users/dunin7/foray is not the implementation repo — foray-api is, and five further sibling FORAY repos exist uninvestigated. Every recent foray commit is docs:. (Section A scope note.)
  2. An in-flight ruling reverses shipped validator behavior with the code change unwritten. R2 RULED PERMIT 2026-08-18 (the HEAD commit); E7/E9 in foray-validate-4-2.mjs implement the narrowing this reverses. The sheet states it "Blocks: all adaptor and reference-implementation work," and five further rulings (R1, R3–R7) are unchecked boxes — R1 could delete "the rule the validator catches most." (foray docs/decisions/foray-validation-scope-decision-sheet-v0_4.md:120-176, :130-138.)
  3. The 4.2 wire is in force with zero published record conformance vectors (F-15 suite "enumerated, not authored" — docs/decisions/foray-fwire-amendment-acceptance-v1_0.md:11); the only CI-gated vectors test anchoring. And the six published transaction types were validated against pre-4.2 foray-api v0.7.0 (transaction-types/index.json:5).
  4. Governing documents disagree with each other and with the schema. Root v0.7 catalogs F1–F25 only while the naming ratification declares "Catalog state on ratification: F1–F29" (foray-root-data-set-v0_7.md:33-63 vs foray-root-naming-ratification-decision-sheet-v1_1.md:35-48); the F8 asset-type reframe landed in the Root but the published schema still comments F8 as "Currency" (…v0_7.md:42 vs foray-transaction-v4_2.schema.json:39-42); Root R5 claims a validation check (recompute F20 from F19) that no validator function performs (foray-validation-scope-decision-sheet-v0_4.md:112).
  5. The whole batch/tier-2/custody subsystem is built and deliberately dark — six briefs of shipped code, BATCH_MODE/UNIFIED_ANCHOR_PATH unset in every environment, arming an explicit separate Operator act. (foray-api wrangler.toml changelog v0.11–v0.17.)
  6. The attestations component class is structurally unvalidated — anything placed there validates (foray-transaction-v4_2.schema.json:51-54). adapters/ is dead code requiring a nonexistent ./foray-sdk.
  7. Recorded self-diagnosed hazard: "reading the validator's behaviour as the specification's intent… twice in one session" (foray-validation-scope-decision-sheet-v0_4.md:180) — a live trap for anyone (including this investigation's readers) inferring protocol meaning from implementation.

Loomworks engine

  1. _AGENT_KINDS no longer means only agents — it aliases {"agent","companion"}, so the Companion is charged against and blocked by the agent spend tier. (B1 citations.)
  2. System processes masquerade as humans to pass the human-authority gates. FORM_SUBMITTER_ACTOR is kind="contributor" explicitly so commit_assertion lets it through (credit/form_submitter.py:16-24); _BOOTSTRAP_ACTOR follows the same precedent. Root cause: ActorKind has no system kind (memory/base.py:22; agents/render_dispatch.py:99). The B3 gates therefore have non-human processes on their permitted side — directly relevant to any Boundaries claim about who can commit.
  3. instruction_version is documented-required for agents, unenforced, and hardcoded to 1 on the live HTTP path (memory/base.py:147; api/deps.py:1099-1104) — R-A24 instruction pinning is nominal.
  4. The wire schema is wider than the substrate for boundary-record deciders (companion kind unproducible — B2), and _record_to_schema is hand-duplicated across two routers (boundary_records.py:76-98, material.py:124-146) — a drift hazard.
  5. The FORAY emitter drops its payload even at DEBUG (reserved_emit.py:33-35), the FORAY_RESERVED_LOCATION marker over-counts emission sites by four, and _ANCHOR_PRIORITY has no credit.* entries — the credit-flow emissions carry no priority signal (anchor_priority.py:30-99 vs flows.py:121-134).
  6. A latent bug in an unused actor constant: RECONCILIATION_SPECIALIST_ACTOR passes name= which Pydantic silently drops (no extra="forbid"), and omits instruction_version (credit/specialists.py:74-78).

Loom

  1. The loom repo is an empty shell (2 files, 239 lines; empty untracked spec/test dirs) and the spec was missing from its own repo at commit time — the canonical spec lives in loomworks-record. The engine exceeds the spec substantially; the engine is the de-facto spec. (Section C layer note.)
  2. The relationship vocabulary is order-locked by a guard test — a containment term for limit trees must be appended, never inserted (memory/base.py:76-77).

GRANTHA

  1. GRANTHA's founding thesis was retired and its replacement is not ratified. Decision N1: "GRANTHA does not do zero-knowledge proving"; the replacement hidden-topology claim N3 is "[INTERPRETATION — ratification owed]" while three documents already lean on it (grantha discovery/GRANTHA_DISCOVERY_RECORD-v0_14.md).
  2. A dissolved fork left a dangling dependency: the grant-scope grammar — the core of what a grant can say — is deferred to the §4.1 fork that the ZK drop dissolved (design/GRANTHA_GRANT_CHECK_CONTRACT-v0_2.md §2).
  3. Discovery Record sources v0.8–v0.11 do not exist as files anywhere (per v0.14's own header sweep); Decision I8 is bound only via a hash-pinned quote extract.
  4. Doctrine and code point opposite directions: doctrine mandates signed, dual-expiry, fail-closed grants; the shipped delegation grant has no expiry and no signature — and grant creation is regex-driven natural language (delegation/schema.py:245-305: a "you can / go ahead and / i authorize you to" prefix mints authority; "without asking"/"whenever" upgrades to pre_authorized). Plus a constraint-check asymmetry: action_context=None bypasses every constraint on the grant (delegation/authorization.py:169-201, documented as intentional).

OVA

  1. The OVA/Stele fence is written down by name — the exact collision the Boundaries design must avoid is already a named refusal in OVA's seed (E2c).
  2. V3_2's FORAY integration is repudiated but not yet edited — F-4's spec pass is unrun; anyone reading V3_2 alone gets an obsolete picture (E3).
  3. Two engine OVA seams overlap each other with no merge plan — verify_companion_authorization has a known signature defect ("fixes the question to delegation"), which is why CR-2026-157 generalized a different ancestor (credit/cross_engagement_memory.py's _alpha_authorizer_stub) into authority/authorizer.py instead. Also: OVA_SKILL.md describes a different OVA (a coding skill) — a naming collision; the Forge-blessed OVA spec is V2 while authoring is at V3.2.

Cross-cutting

  1. stele-agentic-id already implements the two-lane consequence model (reversible clamp / human-gated revocation) that the doctrine assigns to GRANTHA lane 1 (packages/agentic-id/src/agentic_id/clamp.py:1-40, registry.py:214-266), with a foray_mapping.py alongside — and nothing in the engine imports any of it. Three codebases (engine delegation, stele-agentic-id, GRANTHA doctrine) now hold three unconnected notions of narrowing an agent's authority.

Impact list — findings that force changes to solution design v0_2 and the build path, ranked

CC's judgment. Ranked by how much of the design each finding invalidates or unblocks.

  1. The "cop at Loomworks's commit path; FORAY evidences its verdicts" wiring is directionally supportable but neither half exists, and the Loomworks half is mislocated in the design's premise. FORAY-side there is no enforcement point to rely on — the production ingest (POST /api/anchor) commits opaque bytes with no validation, validator never connected to commit (A5) — which confirms the cop must live in the originating system. But Loomworks-side the design's stated precedent ("one limit type, blocking, in the commit path", B1) is wrong on its third clause: the spend gate guards the model-room spend path, while the commit path has a separate human-authority gate, and the FORAY evidence channel is a no-op that has never emitted (B4). Solution design v0_2 must (a) name the real chokepoints it instruments — gated_room_complete, commit_assertion/creation, execute_admission_outcome — as plural, and (b) treat the Loomworks→FORAY emission client as a build-path prerequisite, not an assumption; and it must account for the alarm-driven commit path (A5 entry 8) and the no-idempotency /api/anchor contract if it ever writes FORAY-side.
  1. Plane 2 must be designed as the evolution of verify_companion_authorization, not a sibling. The engine already ships a risk-posture decision point (approval_mode: per_action = summon a human) behind an OVA-labelled seam, with two overlapping seams and no merge plan (E2, Surprise 23). A parallel Plane 2 mechanism would be the third authorizer. This is an architecture decision the design must make explicitly.
  1. The mandate object exists on the wrong side of the seam, and GRANTHA doctrine forbids the obvious mapping. FORAY 4.2's authority-grant Arrangement is exactly the scoped/windowed/digested grant the design needs (D3) — but GRANTHA has zero code, its live stand-in (delegation grants) is unsigned and immortal with regex-minted authority (D2, Surprise 20), and GRANTHA's ruled position rejects surfacing grant lifecycles as readable Arrangements in favour of a blinded envelope that is itself still unruled (D3). If solution design v0_2 assumes boundaries reference visible FORAY Arrangements for authority, it contradicts a standing GRANTHA decision sheet — this needs an Operator-level reconciliation before any increment builds on it.
  1. Limit trees need a protocol addition; the substrate is otherwise ready and the amendment ceremony already exists. Versioned, provenanced, node-citable, time-travelable — all live today, but only flat (C1); the build path should choose route 1 (nodes as objects + an appended containment relationship term — a spec-level change) and reuse the Seed amendment ceremony (draft/converge-or-diverge/Operator-commit, idempotent, stale-base-409) as the limit-tree amendment lifecycle (C2). This removes work the design may have assumed (replay tooling, C3) and adds one Loom spec amendment.
  1. The preflight ("would this succeed?") capability is greenfield (B5) — nothing composes the existing gates into an ahead-of-time verdict, and the one thing named "preview" spends real credits. If the Boundaries cop is to offer dry-run answers, that is new build, and the gate inventory in B1/B3 is its checklist.
  1. The Stele design must reconcile with three facts on the ground: the OVA fence (OVA must never read it — E2c); the engine's actor-identity gaps it would be filling — no system kind, humans-by-masquerade on the permitted side of the human-only gates, instruction_version nominal (Surprises 10–11); and stele-agentic-id, which already implements identity roots + clamp/revoke lanes with a FORAY mapping and is imported by nothing (Surprise 24). Decide: build on stele-agentic-id, or explicitly supersede it. The seed constrains form, not substance: identity stays cryptographic/UUID-class, and the Stele enters the seed (if at all) as a seat, not a mechanism (F2).
  1. Registered streams cannot carry per-engagement Boundaries streams yet. The continuity walk exists verifier-side only; no registry, no producer-side stream_segments, no scope vocabulary (A3) — and the built aggregation tiers are batch-lane machinery, dark and explicitly not streams (A4). Any design element that says "declare a stream per engagement" is spec-writing, not integration, and belongs on FORAY's queue, not the Boundaries build path.
  1. The governance column is carrying-capacity only. agent_activity_record validates as a shape, but F26 is a free string, F15 has no verdict vocabulary, and the F15 code lists are an open catalog item (A2). Boundaries records written today would be well-formed and semantically ungoverned; the design should either author the needed catalog entries as part of the arc or scope verdict semantics inside Loomworks.
  1. Bounded-commitment measures have no home. F7 has no per-family semantics and the governance exemplar carries its scope as free-text residue (A6); an approval ceiling expressed in a FORAY record today is not Root-validated. If Plane 1 enforces ceilings, the ceiling's authoritative copy must live in the limit tree (Loom-side), with FORAY carrying at most its digest — the design should say so explicitly.
  1. The arc's own documents need to land in the record before the design advances. Four of five, including the solution design this investigation was meant to test, exist nowhere in the workspace (F3, Surprise 1) — this findings document cites a §6 it could not read. Committing the arc documents is a build-path step zero.

End of findings v0_1. Read-only investigation; no repository was modified; this file is the sole artifact and is uncommitted — committing is an Operator act.

DUNIN7 · Done In Seven LLC · Miami, Florida

record.dunin7.com prototype · Generated 2026-08-26