DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path investigations/loomworks-agent-admissibility-and-attestation-investigation-v0_3.md

Loomworks — Agent Admissibility and Attestation — Investigation

Version. 0.3 Date. 2026-08-01 Status. Investigation. Poses eight decisions for Operator settlement. Not a change request. Does not amend the seed. Does not touch the build list. Author. Claude.ai. Operator: Marvin Percival. Filing. loomworks-record/investigations/ Companion. loomworks-post-admission-lifecycle-investigation-handoff-v0_1 — opens the arc this document defers. This investigation covers admission as a gate; the companion covers what follows admission as a lifecycle. Supersedes. v0.2 and v0.1 (both 2026-08-01), which stand alongside as siblings.


1. What this is

A single conversational arc, preserved. The Operator brought an external framing — a widely circulated graphic contrasting what people think agentic AI governance is against what it actually requires — and asked what DUNIN7 was missing. The arc that followed moved from a gap analysis, through the mechanism that closes most of the gap, into the question of who or what sits at the root of the trust chain.

This document preserves the trajectory rather than only the destination. Positions asserted and withdrawn during the session are recorded in Section 13 alongside their corrections.

It produces no build work. It produces five decisions. Four of the five are cheap to settle and expensive to leave implicit, because each one is load-bearing for claims that will be made in front of a technical buyer.

What this document is not. It is not a specification for attestation credentials. It is not a change request. It is not a seed amendment, and none of its content should enter the seed at v0.13 — the seed carries commitments, and everything here is an open question. It does not propose a build sequence, because the decisions gate the sequence.


2. The stimulus

Three external inputs entered the session in order.

The governance pyramid. A graphic by Alex Miguel Meyer contrasting twelve common misconceptions about agentic AI governance against twelve stated requirements. The twelve requirements are the gap-analysis frame used in Section 3.

TA-14. A platform at ta14-exchange-platform-theta.vercel.app, authored by Greggory Don Butler, a contributing editor at AutomatedBuildings.com. Its governing principle — no admissible evidence, no admissible execution — is the commit-gate, arrived at from building automation rather than from provenance. Its chain runs Reality, Record, Continuity, Admissibility, Binding, Commit, Execution, Outcome. The idea is sound; the institutional apparatus around it (an "Authority Governance Institution", seven governed doors, a Registry, an Academy, a Partner Review Network, a Marketplace) is vocabulary rather than mechanism. Nothing on the site states how continuity is established, what makes a record admissible, or who verifies.

The incident-plan list. A circulated argument that every production AI system needs an incident plan, with nine questions: what counts as an incident, who is alerted, who owns response, what is paused, what is rolled back, what users are told, what evidence is captured, how the workflow continues, how recurrence is prevented.

Two observations about the stimulus rather than its content.

The idea is in the air. Butler reached the commit-gate independently, from HVAC. Whatever is defensible about DUNIN7 is not the insight — it is the mechanism. This was already the working position; the external convergence is evidence for it rather than a change to it.

TA-14 is the nearest failure mode to DUNIN7's own. Claiming the authority seat by vocabulary. Naming an institution into existence. DUNIN7 has more mechanism than TA-14 does, which is precisely why the temptation is available — the apparatus would be partly earned. Recorded as a specimen, not as a competitor.

Flagged, not acted on. Butler is publishing dated public articles on admissible execution while FORAY sits patent pending. The material is concept-level rather than claim-level, so this is probably nothing. It belongs in front of whoever handles DUNIN7's filings.


3. Where DUNIN7 stands against the twelve requirements

| Requirement | Position | |---|---| | Agent identity and access management | Stele; Stele Agentic ID in build | | Real-time decision audit trails | FORAY — records what, not why | | Dynamic least-privilege permissions | GRANTHA over OVA | | Human escalation trigger design | Step-up authentication; Operator authority over state transitions | | Multi-agent interaction monitoring | Not addressed; in tension with the OVA projection principle | | Cross-system action scope limits | Per grant, yes. Aggregate across systems, no | | Shadow agent discovery protocols | Dissolved by admission control (Section 9), not solved by detection | | Kill switch and rollback | Revocation exists. Rollback is a target-system property (Section 4) | | Continuous behavioural drift detection | Declared out (Section 12) | | Workflow-level accountability mapping | FORAY plus Loomworks | | Third-party agent risk assessment | Becomes admission control (Section 9) | | Incident response for autonomous failures | Two of nine questions are substrate; seven are organisational (Section 12) |

The pattern in the gaps. DUNIN7 is a gate and record architecture. It decides what is permitted before the fact and proves what happened after. The items that fall outside both categories are those requiring a system that watches while things run and one that intervenes when things go wrong.

The absence problem. FORAY is tamper-evident on what is recorded and silent on what was never presented to it. Tamper-evidence does not detect omission. An agent that never writes to FORAY is invisible to FORAY. This is not a defect in the design, but it is a claim boundary a serious buyer will find, and it is better named first than discovered. Sections 4 and 9 are the two independent answers to it.


4. Gated emission

The mechanism that closes the absence problem.

Ungated. The agent acts, then emits a FORAY event. The record is a side effect of the action. It depends on the agent doing what it was instructed to do — which covers well-behaved agents, and well-behaved agents are not the threat.

Gated. The FORAY commit comes first and the action cannot proceed without it. The record becomes the ticket.

Concretely, for an agent posting to an external system:

  1. The agent presents the intended action to the enforcement point — the component that actually releases access.
  2. A FORAY entry is committed describing the intent.
  3. The commit returns a reference.
  4. The enforcement point verifies the reference exists before releasing the grant.
  5. The agent acts.

No committed entry, no grant, no action.

What this changes. Emission moves off the agent's honour and onto the enforcement path. A compromised agent that declines to report does not become invisible; it becomes inert. Silence in the record comes to mean nothing happened rather than nothing was reported. That is the difference between a log and evidence.

Two boundaries.

Coverage equals the enforcement point's coverage. An agent holding direct database credentials or an unmediated API key routes around the gate. The claim is only as wide as the chokepoint.

Intent and outcome are separate records. The gate captures what the agent set out to do. Whether it succeeded, and what returned, requires a post-action entry. Two-phase: intent gated, outcome appended.

On rollback. Complete visibility of what an agent did is not the ability to unwrite it. Reversibility lives in the target system. A complete record yields the ordered compensation plan — what must be reversed, in what sequence — but executing it requires each touched system to support compensating transactions. Some actions are irreversible outright: a sent message, a transfer, a published document.

The defensible formulation is therefore narrower than see it and undo it:

The third line is not a weakness when stated. We give you the ground truth to drive rollback survives a technical buyer's push. We roll back does not.

Agents built by agents. Where a builder-agent mandates FORAY emission in what it constructs, the addition is real but different from what it first appears. It yields the provenance of the agent itself — who specified it, what it was authorised to do, what it was built from, which version is deployed. Runtime records cannot answer what an agent was supposed to do; build-time records can, and that is the expensive question in the first hour of an incident.

The caution is that a build-time mandate is still instruction, moved up one level, and its failures are inherited rather than isolated: a single defect in the builder propagates to everything it built, carrying the same signature of correctness. The mandate survives if it is verified rather than trusted, in two composing ways — a structural check at build time that the emission points are present, and the runtime gate, which holds even for an agent that was built defectively. With both, the builder-agent is a convenience rather than a trust dependency.


5. Attestation: carried or referenced

An agent may need to carry attestation credentials. The design decision inside that is whether the credential carries the claim or points to it.

Carried (bearer attestation). The agent presents a signed document: built by X, structurally verified on date D, declared capabilities C, non-claims N. The verifier checks the signature. Works offline, across trust boundaries, and when the issuer is unreachable. This is the only form that functions for an agent arriving from an environment DUNIN7 cannot query.

Referenced. The agent presents an identifier; the verifier resolves it against the record. Always current, revocation instant, no staleness. Requires the verifier to reach the issuer — which is exactly what fails across organisational boundaries.

The split proposed here. Attestation carries the structural facts — provenance, build lineage, declared capability, non-claims — because those do not change after issuance. If they change, it is a new agent and a new attestation. Grants stay live and re-verified, because authority does change.

> Attestation says what this agent is. Grant says what it may do right now.

Different lifetimes, different mechanisms. Conflating them is how bearer-token problems enter a system that thought it had avoided them.

What this makes possible. A foreign agent presenting attestation is presenting something assessable — not trust my organisation but a set of specific, signed, checkable claims, including the non-claims. The perimeter can then decide admissibility for a narrow scope. That is the bilateral admission protocol named in Section 9.

It also makes the assessment attestable. A DUNIN7 review of a foreign agent produces a finding: dated, attributable, supersedable. Which is a governed record with provenance, and that is the thing already built.


6. Admissibility before grant

Identity is not admission. Grant is the sole primitive. An agent holding a Stele Agentic ID with zero grants can do nothing. Issuing identity early is therefore cheap, and buys a great deal: the assessment becomes recordable. An assessment needs a subject to attach to — attributable, dated, versioned, supersedable. Withhold the identifier and there is nowhere to put the finding.

The ordering inverts from the intuitive one. Identity first, precisely so that admissibility can be assessed against something.

Evaluation sits at grant time, not at identifier creation. This is worth stating flatly because the intuitive reading is the reverse — that an identifier is something an agent earns by passing assessment. It is not. The identifier is the prerequisite for assessment, not its reward. Sequence: identifier issued, structural assessment recorded against it, grants issued narrowly on the strength of that assessment, assessment re-verified thereafter as a standing property.

The practical gain is that a refusal becomes a record. An agent assessed and found inadmissible for a given scope has a dated, attributable finding attached to a durable subject. When it presents again, there is history rather than a first impression. That is only available if identifiers are cheap to issue.

An identifier must not read as endorsement. Cheap issuance creates a hazard the moment Stele Agentic IDs exist in any number: holding one will be read by someone as certification. It is not. An identifier with no grants is inert. But that has to be stated in the same breath as the identifier is issued, and stated on any surface where identifiers are visible, or a badge has been created by accident — the same failure mode as the specimen in Section 2, reached from the opposite direction. Certification is what an attestation plus a recorded finding conveys, and only within its declared scope.

Cheap is not free. Unconditional issuance invites namespace flooding, so issuance eligibility needs a rule. This is D6.

Assessable before any grant. Structural properties:

Not assessable before a grant. Behaviour requires running; running requires acting; acting requires a grant.

Superseded position (v0.1, v0.2). Both prior versions resolved this bootstrap through graduated grants — narrow scope first, high observation, expansion on accumulated evidence — described as a probationary engagement with real mechanics and synthetic stakes. That resolution is withdrawn at v0.3. It is the trust-escalation model, and it does not survive the Operator's objection recorded in Section 8. The prior wording stands here as the surfacing event.

Current position. The bootstrap does not resolve. Each grant is its own decision, assessed on its own terms, and no quantity of prior running licenses the next one. What probation can still do is disqualify: a failure observed under narrow scope is conclusive, and that is a real use. What it cannot do is qualify.

The limit. Static assessment does not catch capability emerging from composition — two safe tools that are unsafe in sequence — nor capability that changes when an underlying model updates beneath a stable configuration. Admissibility is therefore a standing property, re-verified, not a gate passed once. Revocation is what makes it standing rather than historical, which is why D1 (Section 11) is load-bearing here as well.


7. Lineage identity and the environment

A Stele Agentic ID identifies an instance. It is valuable for the life of that instance and worthless afterwards.

The hole that leaves. Section 6 makes refusals recordable — an agent assessed and found inadmissible carries a dated finding attached to a durable subject. But if the identifier dies with the instance, the creator re-creates the agent, receives a fresh identifier, and walks past the record clean. Per-instance identity makes history recordable and escapable in the same move. This alone justifies a second identifier that persists across instantiations.

Two identifiers, not one. The Operator's framing named this a fingerprint. The word carries two opposite properties and the design needs both, so the term is set aside in favour of naming them separately.

Carrying both does not prevent lineage forgery. It makes forgery attributable: a creator who forks lineage to escape a finding does so on the record, under their own key, and the fork is itself the signal. Given foreign agents are excluded (Section 9), creators inside the perimeter are already known principals, so attributable is close to sufficient.

What "same agent" holds constant. A lineage identifier is only meaningful if it declares its invariants. Same code, different prompt. Same prompt, different model. Same everything, different grants. If a model swap preserves the lineage identifier, comparison against prior instances compares two different things and does so with the appearance of rigour. The invariant set is part of D7.

The environment confound. This correction is the Operator's and it is load-bearing. An earlier position in this session held that lineage identity makes part of drift detection deterministic — this instance requested a grant no prior instance in this lineage has requested is a set difference over a discrete record, with no model judging it.

That holds only if the environment is recorded alongside. Agents are created and executed in an uncontrolled environment. Identical code placed into a different environment may behave differently for reasons that have nothing to do with the agent. A difference observed between instances is therefore confounded — the agent changed, or its environment did, and a record that captures only the agent cannot say which. Confounded signal carrying the appearance of determinism is worse than no signal.

What the comparison has to be. Not instance against instance, but pair against pair: (lineage, environment) compared to (lineage, environment). Deviation is attributable to the agent only where the environment side is held constant or its difference is accounted for. The environment therefore becomes an attestable object with its own descriptor and digest.

The asymmetry that helps. Agents may be created in the wild. They do not execute there. Foreign agents are excluded, so execution occurs inside a perimeter DUNIN7 defines. The environment descriptor has an inner half that is recordable and largely already in the record — grants in force, other admitted agents present, engagement scope, substrate version — and an outer half that can only ever be sampled: responses from external systems, data encountered, timing, load. The inner half is knowable. The outer half is not, and no descriptor design will make it so.

This is D8. It also argues that the execution environment is a governed object in its own right, which is larger than the identity question and is carried to the post-admission arc rather than settled here.


8. There is no such thing as a trusted agent

The strongest position in this document, and it arrived by the Operator rejecting the one that preceded it.

The objection. Trust escalation assumes environmental constancy. The environment and the data are not known ahead of the trust decision, and cannot be. Evidence gathered under one set of conditions does not license action under another.

The circularity underneath it. Expanding a grant does not merely risk environment drift. It causes it. The evidence was gathered under precisely the conditions the expansion destroys. Good behaviour within a narrow scope is offered as grounds for leaving that scope, and the leaving invalidates the evidence. This is not weak inference; it is circular inference.

The adversarial edge. Environment is not only uncontrolled variance. It can be chosen. An agent that behaved well on benign data says nothing about its behaviour on data selected to break it. Trust escalation quietly assumes benign variance, and that assumption is unavailable in the environment this architecture is built for.

What survives.

Negative evidence is asymmetric. An observed failure is conclusive. An absence of observed failure is not. Probation is therefore sound for disqualification and unsound for qualification — the reverse of how it is usually sold.

Conformance is more portable than competence. Whether an agent emits when required, remains inside its declared capability, and never requests a grant outside its declaration are properties of the agent's relationship to its own declaration, and they travel across environments reasonably well. Whether its judgement is sound under novel conditions is entirely environmental. Probation can check the first and cannot check the second, and the two are conflated every time someone says an agent is proven in production.

The architectural consequence. DUNIN7 must not have a trust score.

Grant is the sole primitive. A trust level is a second primitive smuggled in — a summary statistic standing in for assessment, which is exactly the probabilistic inference dressed as determinism that the architecture rejects everywhere else. There are no trusted agents. There are agents holding grants, each assessed on its own terms at issuance and re-verified thereafter.

The correct shape is therefore not escalating trust but more narrow grants, each independently gated. From outside these look similar. Architecturally they are not: nothing accumulates, nothing is inherited, and no expansion is justified by history.


9. Foreign agents and the perimeter

The Operator's position: within the DUNIN7 framework of operation, foreign agents are not permitted.

This is the same move as the OVA reach inversion. There, the membership predicate turned a sixty-three-endpoint read-side problem into a single fence. Here, the admission predicate turns detect misbehaving foreign agents into there are none. Define the boundary rather than police the interior.

What it closes. Shadow agent discovery is dissolved rather than solved: an agent without a Stele Agentic ID and a grant is not an actor in the environment, it is an outsider knocking. Third-party agent risk assessment becomes admission control rather than continuous monitoring.

What it does not close.

Admitted agents still fail. Foreign is a provenance property, not a behavioural one. A DUNIN7-built agent with a bad specification, a stale grant, or a corrupted input does damage from inside the perimeter with full credentials. The gate in Section 4 is what stands between a defective member and an unrecorded action. Admission control and gated emission are independent answers to the absence problem and neither substitutes for the other.

The perimeter has edges DUNIN7 does not control. An agent calling an external service is an outbound action — gated and recorded, fine. But where a counterparty's agent must transact with a DUNIN7 agent, not permitted means either no transaction or an admission pathway for agents DUNIN7 did not build. Two Loomworks environments, different legal entities, each with its own admission rules.

This is D2.


10. The human root

Attestation is only as good as the attester, and the regress is real: who attests the builder-agent, and who attests them. Every public-key infrastructure meets this and every one resolves it by declaring a root.

The Operator's position: at the root must be human governance.

This is where the chain can terminate. Machines can carry attestation. They cannot originate accountability.

Reconciling this with the record. An earlier position in the session held that accountability must reside in the record rather than the org chart. That reads as tension with human governance at the root, and is not. The org chart fails not because humans cease to be accountable but because at agent volume the mapping from action to human becomes untraceable. The record does not replace the human root; it makes the human root findable from any action, however many hops down. Record as the path, human as the terminus.

What the human act is. Not approval per action — that is the item on the wrong half of the governance pyramid. It is constitutional: who may attest, what admission requires, what an attestation means, when it is revoked. Rare, deliberate, recorded. The Operator's Go is already this shape.

This is also why it scales. Human governance holds at the constitutional layer and collapses the moment it leaks into the operational layer. Keeping the two separate is the design work.

Where DUNIN7 is well placed. Most agent-identity work starts with agents and bolts on a principal afterwards. Stele — human identity — was built first, Stele Agentic ID second. If every agent identity resolves to a human principal by construction, the root is a structural property of the identity layer rather than an asserted policy.

Two things to hold honest. A nominal human root is worse than none: it launders machine decisions through a name nobody can trace to a decision. The record must show the human actually decided. And roots are mortal — people leave, die, lose keys. Root succession is the question every public-key infrastructure handles badly, and it is D5.


11. Decisions for Operator settlement

D1 — Grant lifetime. Is a grant a bearer token, or a claim re-verified at each action? Revocation exists in GRANTHA. This decision determines whether revocation reaches a running agent or only the next session. Bearer tokens cannot be revoked, only expired. If the answer is re-verified, the freshness window becomes the entire performance story and must be a stated figure rather than an implied instant — how fast is your kill switch has a number for an answer. Load-bearing for Section 6 as well: admissibility as a standing property requires re-verification to exist. Sub-question if re-verified: where no single object holds the complete picture, revocation must reach every object in the chain. Is that propagation atomic, and what may an agent do in the interval where some objects have revoked and others have not?

D2 — Foreign agents. Permanent architectural exclusion, or correct v1 boundary? Permanent makes DUNIN7 a closed governed estate: strong claim, bounded market. Correct-for-now means the eventual work is a bilateral admission protocol — what a foreign agent must present, what it receives, what record both sides keep. Claude's lean: the second, stated as the first for now. This is a positioning decision, not a technical one.

D3 — Evidence layer unavailable. Fail-closed, bounded degraded mode, or fail-open? Gated emission makes FORAY a dependency of every governed action. If it is unreachable, everything halts. Fail-closed is defensible and probably correct, but it introduces a single point of failure created by the governance mechanism itself, and the first serious buyer will ask for the availability number. Fail-open is worse: an outage becomes an unrecorded window, and an attacker who can cause an outage can act unobserved. The real question is whether a bounded degraded mode exists — a local durable queue, actions permitted but marked provisional, reconciled on recovery.

D4 — Root of trust scope. Is DUNIN7 a root of trust in its own estate only, or does it claim to be one generally? Own-estate is defensible and probably correct. The general claim is the coat TA-14 is wearing.

D5 — Root succession. What happens when the human root leaves, dies, or loses keys? Should be answered before the human root is claimed as a strength rather than stated as a position.

D6 — Issuance eligibility. Who may request a Stele Agentic ID, and on what condition? Identifiers must be cheap enough that refusals are recordable and history accrues, and constrained enough that the namespace cannot be flooded. Claude's lean: a human principal must be attached at request time. The Stele-first architecture supplies this naturally — every agent identity resolves to a human principal by construction — so the rule is a consequence of the existing identity layer rather than a new mechanism. Carries a paired surface obligation: wherever an identifier is visible, its inertness must be visible with it (Section 6).

D7 — Lineage identity. Does an agent carry a creator-declared lineage identifier alongside its per-instance Stele Agentic ID, and what does it hold constant? Without one, a finding against an agent is escaped by re-creation. With one, forgery becomes attributable rather than prevented. Claude's lean: carry both a declared lineage identifier and a derived per-instantiation build digest. The harder half is the invariant set — whether a model swap, a prompt change, or a capability-declaration change preserves lineage. An identifier that survives a change it should not have survived makes comparison lie with the appearance of rigour. Prior art should be surveyed before drafting: image digests, code signing with publisher identity, and software bills of materials are adjacent, and agent-identity standards may have moved.

D8 — Environment descriptor. What is recorded about the execution environment, and what is conceded as unrecordable? Lineage comparison is confounded without it (Section 7). The inner half is knowable and largely present already — grants in force, other admitted agents, engagement scope, substrate version. The outer half — external system responses, data encountered, timing, load — can only be sampled. The decision is where the line falls and how the unrecorded half is disclosed, because a comparison presented without its confound stated is a claim the record cannot support. Feeds the post-admission arc's question of whether the execution environment is itself a governed object.


12. Declared out of scope

Naming what DUNIN7 does not do is as important as naming what it does. It is what separates the suite from the specimen in Section 2.

Continuous behavioural drift detection. Inherently probabilistic. The established discipline holds: probabilistic systems may inform or propose; deterministic gated systems record. Drift detection belongs upstream as an input, not as a DUNIN7 capability. This is a declaration, not a gap.

Tested and held at v0.3. Lineage identity (Section 7) appeared briefly to bring part of this back inside, on the grounds that a set difference over a discrete record — this instance requested a grant no prior instance in this lineage requested — needs no model to evaluate it. The environment confound defeats that. Without a recorded environment on both sides of the comparison, the difference is not attributable to the agent, and a deterministic-looking output that cannot support its own attribution is worse than none. If D8 settles with a usable environment descriptor, the narrow deterministic case may be revisited. Until then the declaration stands unchanged.

Rollback execution. A target-system property. DUNIN7 produces the compensation plan; the target systems execute it or cannot.

Multi-agent interaction monitoring. In unresolved tension with the OVA projection principle. OVA exists to make topology unobservable — zero structural correspondence between what an actor sees and the actual graph. Monitoring requires exactly the observation position OVA is designed to eliminate, and whoever holds that position becomes the concentrated target OVA was built to remove. This is not an oversight to patch; it is a design question needing an answer before either capability is claimed. Filed open, not declared out.

Seven of the nine incident-plan questions. What counts as an incident, who is alerted, who owns response, what is paused, what users are told, how the workflow continues, how recurrence is prevented — these are organisational, not substrate. Two are substrate, and are the two that cannot be retrofitted: what evidence is captured is decided before the incident or not at all, and what gets rolled back resolves to the compensation plan above.

Two quiet benefits worth noting where the substrate does help: who gets alerted is derivable rather than a rota, because the responsible principal for the action is in the record; and what users are told becomes bounded disclosure — these forty-one records were touched, these were not — rather than the honest but unusable we do not yet know the blast radius.


13. Corrections preserved

Positions asserted during the session and subsequently corrected, recorded alongside their corrections per the Discovery-record posture.

Kill switch listed as absent. Asserted in the initial gap analysis. Corrected by the Operator: revocation exists. Resolution: the kill switch is present subject to D1; rollback remains a target-system property. The prior position was wrong on kill switch and right on rollback, and the two had been wrongly bundled as one line item.

"There is no kill switch to build." Asserted conditionally on grants being one-time issuances. Withdrawn as premature — it presupposed the answer to D1 rather than posing it.

Builder-agent mandate treated as primarily a risk. The initial response emphasised that build-time mandate is still instruction. Correct but incomplete: it under-credited what build-time records add, which is agent provenance — a class of evidence runtime records structurally cannot produce. Both halves now stand in Section 4.

"Accountability must reside in the record rather than the org chart." Asserted as a forward-look. Corrected by the Operator: at the root must be human governance. Resolution in Section 10 — record as the path, human as the terminus. Not a reversal; the original phrasing was too strong and read as displacing the human principal rather than locating it.

"Issuing identity early costs nothing." Asserted at v0.1 §6. Corrected at v0.2 following the Operator's question about whether agents must be evaluated at identifier creation. The claim was right that identity is not admission and wrong that issuance is free: unconditional issuance floods the namespace, and identifiers held in any number will be read as endorsement unless their inertness is stated on the surface. Replaced by cheap is not free, D6, and the endorsement paragraph. The prior wording stands as the surfacing event for both.

Graduated grants as the bootstrap resolution. Asserted at v0.1 and carried unchanged at v0.2, Section 6: narrow scope first, expansion on accumulated evidence, framed as a probationary engagement. Withdrawn at v0.3 on the Operator's objection that trust can only be assumed where environmental factors are constant, and the environment is not known ahead of the trust decision. The withdrawal is not a softening — the position was circular, because the expansion destroys the conditions the evidence was gathered under. Superseded text stands in place at Section 6; the resulting position is Section 8. The bootstrap it was solving is left genuinely open.

\"Lineage identity makes part of drift detection deterministic.\" Asserted at v0.3 drafting time, immediately before the Operator's environment objection. Corrected within the same exchange: the comparison is confounded unless the environment is recorded on both sides. The claim was right that a set difference needs no model and wrong that the difference is attributable. Recorded because the error is the interesting kind — a correct mechanism producing an unsupportable conclusion.

Fingerprint as the term for lineage identity. The Operator's word. Set aside at v0.3 in favour of naming two objects separately, because a fingerprint in the forensic sense is derived and unforgeable while a creator-assigned label is declared and forgeable, and the design needs both properties from different objects. Recorded as a vocabulary decision rather than a correction of substance — the Operator's proposal was right; the single word could not carry it.

Tone. The Operator named a stretch of the exchange as pedantic. The substantive points survived the correction; the framing did not. Recorded because the failure mode is real and recurring: qualifying a correct Operator position into apparent disagreement rather than affirming it and naming the single boundary that matters.


14. Roadmap placement

This does not enter the current arc. At the time of writing, B-29 and B-5 are in flight against build list v0.8. Adding items from here would bump the build list underneath a session orienting on v0.8. Nothing in this document is urgent enough to justify that. Build-list absorption waits until the current arc reaches a halt.

This does not enter the seed. B-16 has seed v0.13 approved for drafting. Nothing here belongs in it. The seed carries commitments; this document carries open questions.

What this document does not cover. Admission is a gate. What follows admission is a lifecycle, and the two are different questions — grant accumulation, composition across admitted agents, delegation, substrate mutation beneath a signed configuration, standing and expiry, exit, load on the human root, and the standing of agent-authored records. Those open as their own arc under loomworks-post-admission-lifecycle-investigation-handoff-v0_1. Folding them into this document would blur both.

Sequence. Settle D1 through D8. D1 and D3 are near-term and touch existing substrate. D2 and D4 are positioning and can hold. D5 should be answered before the human root is used as a claim. D7 and D8 are paired — a lineage identifier without an environment descriptor produces confounded comparison, so neither should be built alone, and D7 warrants a prior-art survey before drafting. Only after settlement does any of this become build list material, and it should enter as discrete items rather than as a programme.

Version-state caveat. Build list v0.8, record HEAD 403790a, B-27/B-28/B-29 open, seed v0.12 canonical with v0.13 approved for drafting, manifest v0.76 plus amendment — all sourced from past-chat retrieval in this session, not repo-verified. Re-read before acting on any of it.


15. Provenance notes

Produced in a single conversational arc on 2026-08-01 in the Claude.ai Loomworks project, from an image the Operator supplied, a URL the Operator supplied, and a circulated text the Operator pasted. Repository state was not inspected; no Claude Code session ran during the arc. Every version number in Section 14 is second-hand.

The trajectory worth preserving: the session moved from what are we missing (an inventory question) through how do we make the record trustworthy (a mechanism question) to what terminates the trust chain (a constitutional question). The inventory framing produced a list of twelve; the mechanism framing collapsed several of them; the constitutional framing produced the five decisions. An inventory answered as an inventory would have produced a roadmap of twelve build items, most of them wrong.

The strongest single commitment in the document is the attestation/grant split in Section 5 — structural facts carried, authority re-verified. It should not be re-litigated each time attestation comes up.

v0.2 and v0.3 were produced in the same session. v0.2 came from a single Operator question — whether agents must be evaluated at identifier creation — which surfaced that v0.1 had left the ordering implicit and had overstated the cost of issuance. One question, two additions and one correction. Worth noting as a pattern: the ordering was correct in v0.1 and simply unstated, and unstated correct positions read as absent ones.

v0.3 came from three consecutive Operator interventions — a proposal (persistent lineage identity), a correction (environment disrupts behaviour independently of code), and a rejection (trust escalation is unsound because the environment is unknown ahead of the decision). Each one improved on what preceded it, and the third withdrew a position both prior versions had carried. The document is stronger for having been wrong twice in public. The section-8 title is the Operator's line, quoted.


16. Version history

v0.3 (2026-08-01). Amendment following the lineage-identity proposal, the environment-confound correction, and the rejection of trust escalation. Two new sections: 7 (lineage identity and the environment) and 8 (there is no such thing as a trusted agent). Former sections 7 through 14 renumber to 9 through 16. Section 6's graduated-grants bootstrap resolution is withdrawn and preserved in place as superseded. Section 11 gains D7 (lineage identity) and D8 (environment descriptor), paired. Section 12 records the drift-detection declaration as tested and held rather than revised. Section 13 gains three entries, one of them a correction made and absorbed within the drafting exchange itself. Section 14's sequence line extends to D8. This is the first version in which a position carried by every prior version is withdrawn.

v0.2 (2026-08-01). Amendment following the Operator's identifier-creation question and the decision to open the post-admission lifecycle as a separate arc. Section 6 gains three paragraphs — evaluation at grant time rather than identifier creation, the identifier-is-not-endorsement hazard with its surface obligation, and the cost qualification. Section 11 gains D6 (issuance eligibility) with a lean toward a human principal attached at request time. Section 13 gains the issuing identity costs nothing correction. Section 14 gains an explicit scope boundary and the companion pointer. Masthead gains the companion and supersession fields. No position from v0.1 is withdrawn other than the one recorded in Section 13.

v0.1 (2026-08-01). Original. Twelve-requirement mapping, gated emission, the attestation/grant split, admissibility before grant, foreign-agent exclusion, the human root, five decisions, three declared out of scope, five corrections preserved.


DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Agent Admissibility and Attestation — Investigation — v0.3 — 2026-08-01