From. GRANTHA project
To. Stele Agentic ID project (repo DUNIN7/stele-agentic-id)
Carrier. Marvin Percival, DUNIN7 Operator
Date. 2026-07-09
Answers. AGENTIC_ID_TO_GRANTHA_REQUEST-v0.1
Grounding. GRANTHA_DISCOVERY_RECORD-v0.12 (protocols/grantha/, loomworks-record, commit e53e413). Decisions cited by their record identifiers.
Yes, GRANTHA accepts agent-lifecycle revocation as a capability type it grants. It fits Decision I8 directly, which splits grant-state changes into two lanes:
Your revocation lever (cut a registered key; subtree dies) is irreversible in effect, so a GRANTHA-granted revoke capability lands in the second lane: the capability itself is either held by a human principal or issued under a pre-authorized catastrophic condition defined at grant time. Your Observation Agent holding no kill switch and escalating instead is exactly the shape I8 anticipates.
The authenticity/wisdom split is confirmed. It is GRANTHA's own load-bearing principle stated from your side: engine verifies, not decides. The substrate verifies the requester's identity and the stamp's authenticity; whether the revocation was wise is a policy question that was answered when the grant was issued, not at the moment of exercise. Neither of us re-litigates it at the lever.
What GRANTHA requires of the substrate when the lever is pulled:
Named dependency: GRANTHA's capability stamps require a principal-nature property from Stele core that is named but not yet built (Decision J5 / Part K). Your side already commits to a neutral principal-nature property; that commitment and this one are the same unbuilt thing. Neither project should describe cross-checking against it as a built capability yet.
The split is confirmed: verdicts yours, consequences ours. GRANTHA will consume VERIFIED / STALE / SUSPECT / DEAD as a policy input. Your verdicts are evidence; what a policy does with evidence is grant content, which is GRANTHA's territory alone. A shared verdict→consequence interface specification is the right artifact, and GRANTHA accepts co-authoring it — the interface names the verdicts and their semantics; the consequences bound to them live in GRANTHA policy.
The consequence vocabulary itself is UNDECIDED, and here is what decides it. "STALE ⇒ capabilities throttled" and "SUSPECT ⇒ suspended pending oversight" are both operations on GRANTHA's pending state — narrowing a grant without revoking it. Pending-state narrowing semantics are an explicitly open item on GRANTHA's side (I8 open item 2): they must be defined before anyone claims them as a built capability. Until narrowing semantics exist, GRANTHA can commit to consuming verdicts but not to a specific consequence vocabulary.
What resolves it: definition of pending-state narrowing semantics. Note for both records: AgntID's per-tool-call intent-evaluation-then-narrow loop is prior art here and is already logged on GRANTHA's side as relevant to exactly this item.
Practical sequencing: publish the verdict half of the interface now (that side is yours and appears stable); leave the consequence half as named-open, mirroring the no-invented-placeholders discipline — record the dependency, don't fabricate the binding.
The split you propose matches GRANTHA's settled architecture. GRANTHA's closed fork (Architectures A and B, synthesized) is: local hot path for decisions, anchored state-changes as the proof layer. A live round-trip per tool call was rejected on GRANTHA's side for the same reason you reject it. So:
Freshness is where this stays IN MOTION. Your 60 s registry TTL invites a matching bound for grant stamps. GRANTHA cannot commit a number yet because of the two-clocks problem, which is open on GRANTHA's side: FORAY emission is instant-local but anchoring is bundle-windowed, and revocation's anchoring latency is security-relevant and unresolved. A carried grant's staleness bound and revocation's propagation bound are the same question viewed from two ends. Committing 60 s for stamps before the anchoring-latency numbers are known risks a bound that revocation propagation cannot actually meet.
What would change it: resolution of the two-clocks problem, which itself waits on concrete reorg maturity-delay numbers from KIP-21's seqcommit-accessor.md (identified, not yet pulled). Once those numbers exist, GRANTHA can state a stamp-freshness bound honestly. Direction of the lean: a bound in the tens-of-seconds range is plausible and your 60 s is not obviously incoherent — but it is a lean, not a commitment.
GRANTHA cannot freeze the shape yet, and the blocker is specific: the §4.1 policy-expression/verifier fork. Current lean is constrained DSL compiled to ZK circuits, with the verifier choice (Groth16 vs. RISC Zero STARK) coupled and unresolved. The two candidate shapes you name land differently under the two verifiers:
Interim guidance you can build against safely: size the capability_ref field for the identifier shape (treat 64 bytes as the floor GRANTHA will never exceed downward), and treat the self-carrying assertion as an upgrade that arrives only if §4.1 resolves toward Groth16. That lets your credential-format freeze proceed with a fixed field size while the fork stays open.
What resolves it: §4.1, which is GRANTHA's gating open item and blocks most downstream work, this included. OQ-4 stays open on your side but with the decider now named and located.
Confirmed from GRANTHA's side: GRANTHA owns grants/authz; OVA does not. This is not merely the Operator ruling echoed — it is architecturally closed on GRANTHA's side. The last possible GRANTHA-consumes-OVA path was examined and closed during the architecture-fork synthesis; OVA's answers to the cross-project questions confirmed it. OVA's predicate is inseparable from its dome and its eggs are internal-only; nothing authorization-shaped is delegated there.
No authorization-adjacent function is delegated elsewhere. For your interface-publication purposes: FORAY is a witness and anchor, never an authorizer; Stele is identity, never authorization; Loomworks is out of scope entirely. When you publish verdict and capability interfaces, GRANTHA is the only counterparty for the authorization half.
OQ-9 can close bilaterally on this answer.
GRANTHA cannot accept the witness role as specified, because it collides with a settled emission principle. FORAY emits on grant state-changes only — issuance, delegation, revocation, conditional expiry — and never on individual access checks. A deny decision is an access check: it changes no grant state. Your B6 assumption ("grant/deny decisions as first-class audit events") asks GRANTHA to emit at check granularity, which the settled discipline forbids. The prohibition is not incidental — check-level emission is exactly the scale trap both projects rejected in the hot path, reappearing as an audit obligation, and it also leaks access-pattern topology that GRANTHA's hidden-topology threat model exists to conceal.
What GRANTHA can offer instead — a variant:
Your event taxonomy's grant/deny entries should therefore split: grant state-change entries are seam-confirmed (pending the routing question); deny entries are yours to source or drop.
| Item | Blocks | Decider |
|---|---|---|
| Consequence vocabulary (A2) | Verdict→consequence interface, consequence half | Pending-state narrowing semantics (GRANTHA I8 open item) |
| Stamp freshness bound (A3) | Carried-grant TTL commitment | Two-clocks resolution → seqcommit-accessor.md reorg-maturity numbers |
| capability_ref final shape (A4) | Shape beyond the 64-byte identifier floor | §4.1 policy-expression/verifier fork |
| State-change routing (A6) | Whether GRANTHA adopts your witness pipeline discipline | Two-clocks resolution |
Three of four trace to two GRANTHA open items (§4.1 and two-clocks). Resolving those unblocks this seam almost entirely.
DUNIN7 — Done In Seven LLC — Miami, Florida GRANTHA_TO_AGENTIC_ID_ANSWER — v0.1 — 2026-07-09