FUURAA AI Civilization Architecture · Operating-layer engineering dossier
Revocation propagation: make stop travel faster than action
Revocation is not a database flag or one successful endpoint response. An effective stop must travel from the authority issuer through decision caches, active sessions, delegation descendants, orchestration queues, retries and tools to every boundary where a new effect could still occur—and leave evidence of what closed, what remained and when.
Public statusResearch direction · architecture referenceEvidence statusFUURAA method synthesis grounded in primary standardsSources checked19 August 2026
Core decision
Can one revoked authority stop every queued, cached, delegated and retried descendant before another effect occurs?
Use this sequence for architecture review, threat modelling and test planning. It is not a universal compliance checklist and cannot replace system-specific engineering validation.
01
Inventory active authority and descendants
Resolve the ancestor authority, issued descendants, active sessions, caches, queues, retries, tools and pending effects before declaring a propagation target.
02
Define the stop event and effective time
Assign an authenticated event, monotonic sequence, affected scope, descendant rule, observed time and effective time without exposing sensitive reason detail.
03
Fan out revocation with monotonic state
Deliver the stop state to every subscriber with acknowledgements, deadlines and retries so stale, duplicate or out-of-order messages cannot restore authority.
04
Block effect boundaries and reconcile races
Re-check authority immediately before consequential effects, cancel queued and retried work, and reconcile any action that crossed the boundary during propagation.
05
Prove closure and residual exposure
Collect receiver state, propagation latency, in-flight outcomes, compensation status and unresolved offline nodes into a reviewable closure record.
FUURAA analysisFUURAA treats revocation as a distributed safety action, not an administrative update. The critical measure is not whether one endpoint returned success, but how long it took before no receiver could create a new effect. Stop state should therefore be monotonic, effect boundaries should re-check authority, and every unresolved recipient should remain explicit. Short expiry limits exposure, but it does not replace active revocation and closure evidence.
Minimum interface contracts
Put consequential semantics in inspectable interfaces instead of relying on assumptions between systems.
Field names are public engineering references, not a normative protocol. Implementations may use other structures, but should expose every lost, defaulted or downgraded semantic.
01
Revocation-event contract
Must be intelligible to sender, receiver and independent reviewer.
Minimum fields
event ID, authority or ancestor ID and authenticated issuer
observed time, effective time and monotonic sequence
affected scope, descendant rule and reason class
Evidence gate
Stale, duplicate and out-of-order events cannot re-enable an authority that has entered a stopped state.
Stop condition
If the contract is unresolved, expired or silently downgraded, block consequential action and route to review.
02
Enforcement and propagation contract
Must be intelligible to sender, receiver and independent reviewer.
Minimum fields
subscribers, caches, sessions, queues, retries and tools
acknowledgement, deadline, retry and escalation state
effect-boundary active check and fail-closed rule
Evidence gate
Every consequential receiver can decide whether authority is still active at the exact boundary where an effect would occur.
Stop condition
If the contract is unresolved, expired or silently downgraded, block consequential action and route to review.
03
Closure and residual contract
Must be intelligible to sender, receiver and independent reviewer.
Minimum fields
descendant inventory and receiver acknowledgements
in-flight effects, cancellations and compensation results
unresolved caches or offline nodes, owner and review time
Evidence gate
The record distinguishes complete, partial and unknown closure instead of converting missing evidence into success.
Stop condition
If the contract is unresolved, expired or silently downgraded, block consequential action and route to review.
Failures to seek deliberately
Verify that boundaries really deny, stop and preserve evidence.
Nominal success cannot establish an effective boundary. Tests should manipulate identity, time, version, network, policy and partial failure while retaining raw outcomes.
T1
Stale cache after revocation
Keep a prior active introspection or policy result in cache, revoke the ancestor, and require a fresh effect-boundary denial.
T2
Queued and retried descendant race
Revoke authority while one descendant is queued and another is retrying; neither may create a new effect after the effective time.
T3
Out-of-order and duplicate revocation
Deliver older, newer and duplicate events in adversarial order and verify that stopped state remains monotonic.
T4
Offline receiver or lost acknowledgement
Withhold one receiver acknowledgement and require explicit partial or unknown closure, escalation and residual exposure.
Minimum engineering evidence package
Let the next owner reproduce the decision, open artefacts and see remaining unknowns.
A complete package only makes evidence relationships reviewable; it does not prove artefacts authentic, controls effective, the system safe or the decision correct.
01
Issued revocation event
Authenticated event identifier, ancestor, scope, descendant rule, sequence, observed time and effective time.
02
Authority dependency graph
Active descendants, sessions, cached decisions, queues, retries, tools and pending effect boundaries.
03
Propagation acknowledgement trail
Receiver acknowledgements, attempts, latency, deadlines, failures, escalations and last known state.
04
Effect-boundary decision trace
Authority state, policy version, cache freshness, decision and resulting effect or denial at each boundary.
05
Closure and residual-exposure record
Complete, partial or unknown closure; in-flight outcomes; compensation; unresolved nodes; owner and review time.
Applicability boundary
This public research reference is not a FUURAA revocation protocol, credential or token format, incident-response service, production control, legal termination notice or compliance determination. Structural propagation cannot establish valid identity or authority, prove every effect stopped, show compensation succeeded, or terminate a legal relationship; consequential use requires system-specific design, testing, recovery planning and accountable approval.
Primary sources and evidence boundaries
Use standards language without presenting citations as implementation evidence.
Every source states publication timing, its role in this dossier and its non-transfer boundary; living source pages were checked 19 August 2026.
