Twelve failures. One architectural problem.

The discovery was the relationship

I found twelve different classes of Hermes issues that were expressions of the same problem. They appeared in Desktop routing, deployment, recovery, GitHub automation, state publication, and message delivery. Their symptoms belonged to different subsystems. Their underlying failure had one shape: a proof was established at one boundary, weakened as it crossed the system, and accepted in that weakened form when something consequential happened. I brought those incidents into one model and corrected that discontinuity in the architecture. The resulting public synthesis is the Hermes Authority Execution Layer, #95028.

The distinction matters. A profile can be correctly selected while a later operation uses a different owner. A permission can genuinely exist while failing to authorize the target object. A build can pass source tests while the delivered application behaves differently. These are locally convincing facts that become globally unsafe when the relationship between the fact and its intended use disappears.

My contribution is the synthesis and its structural correction: an unbroken path from admission through projection and mutation to settlement. The issue histories preserve the individual reporters, implementers, and reviewers whose work made that synthesis possible. The public attribution record is part of the architecture’s evidence, not a footnote to it.

Read the twelve as one system

The twelve core issues in the synthesis are a deliberately defined set. They are different from the fourteen captured issue titles carrying the exact [Architecture] marker. A title search is useful for navigation; it cannot substitute for the membership and relationships stated in the architecture itself. The master issue’s origin table and origin-chain record define the programme discussed here.

Boundary	Manifestation	Public architectural owner
Admission → projection	Qualified identity is weakened and reconstructed	#90142
Admission → projection	Desktop connection and profile identity lose continuity	#88680
Projection	Route identity can change beneath an operation	#90149
Projection → mutation	A narrow proof authorizes a broader effect	#90144
Mutation	Metadata authority is mistaken for repository-object authority	#90200
Mutation → settlement	A stale actor acts on a successor generation	#90145
Mutation → settlement	Installation, update, and activation lack one transactional plan	#88683
Projection	Observable state arrives without the proof needed to use it	#90866
Settlement	Completion is claimed without evidence of the exact object	#91230
Several boundaries	Bot identity and capability are inferred from mutable coordinates	#91911
Projection → settlement	Delivered behavior diverges from the source that was checked	#90150
Every boundary	Ambient coordinates acquire authority they do not establish	#93943

This grouping is analytical compression: twelve incident families become one tractable question. Does the evidence authorizing this operation still describe this actor, this target, this generation, and this effect at the boundary that performs it? The model makes it possible to review a Desktop change and a process-lifecycle change as instances of one preservation obligation, while retaining their different owners and implementation details.

Identity has to survive the journey

Consider two backends that each contain a profile named default. The name identifies a candidate within a context; it does not identify which backend owns the requested work. Once the route has been resolved, dropping its connection dimension and reconstructing it from the current foreground selection creates a second, potentially different resolution. #88680 distinguishes route identity, backend ownership, resource identity, and foreground selection precisely because those concepts answer different questions.

#90142 generalizes the requirement: identity qualification must remain monotonic across subsystem boundaries. Information needed for ownership cannot become optional metadata downstream. A resource facade, cache key, persisted reference, or callback must preserve the identity established upstream rather than infer a plausible replacement later.

Time adds another dimension. A logical resource can retain its name while its owner or incarnation changes. #90145 separates stable identity from generation identity. A delayed recovery operation needs to prove that it still addresses the incarnation it observed. A familiar identifier, recent heartbeat, or existing process slot does not provide that proof by itself. The architectural correction places the generation comparison at the mutation boundary, where it can govern the actual effect.

Authority cannot grow in transit

#90144 names a related failure: an observation about one object, interval, or generation authorizes an operation over a larger scope. The evidence may be correct and the effect may still exceed it. This is why scope must be an explicit property of the proof and the operation, rather than an inference from a successful preflight.

The GitHub case makes the distinction unusually legible. #90200 records an integration that could modify issue and PR metadata while repository-object mutations failed. “Connected” and “writable” were insufficient descriptions. The relevant question was which principal could perform which operation on which installed repository object. Commenting on work and committing the work crossed different authority boundaries.

The synthesis formalizes effective authority through intersection: requested authority is constrained by policy, credentials, and target authority. Delegation may narrow that result; crossing a boundary cannot silently enlarge it. These are published properties of the six-primitives specification.

The correction: one continuous authority path

The architecture fixes the shared structural problem with six cooperating primitives. Their purpose is to preserve the justification for an effect until the component responsible for that effect validates it.

Primitive	The question it answers	Architectural obligation
Identity	Who and what?	Preserve qualified identity and retired-identity semantics.
Scope	How far?	Keep the operation within the authority actually established.
Generation	How current?	Reject stale authority at the effect boundary.
Settlement	What happened?	Bind the outcome to an exact target, attempt, and observed postcondition.
Refusal Algebra	What failed?	Preserve typed causes and the evidence available about external effects.
Execution Layer	Who enforces it?	Make admitted authority a prerequisite of the component that performs the effect.

The public specification connects these primitives through admission → projection → mutation → settlement. A carrier preserves admitted authority; the consuming boundary checks it; the ledger records what occurred; the sink registry defines where consequential operations are permitted. This is the architectural answer to the twelve failures, rather than twelve independent conventions asking future callers to remember the right thing.

Refusal Algebra has its own formal owner, #95750. It distinguishes settlement, authority refusal, structural rejection, and machinery fault. It also keeps knowledge of external effects separate from the result category. An interrupted operation may have produced an effect even when the caller lacks its receipt. That uncertainty calls for reconciliation; it does not automatically justify replay. The specification credits the earlier work on typed results, capabilities, and distributed uncertainty from which its named integration develops.

Completion belongs to the delivered object

The end of the path is as important as the beginning. #90049, an adjacent false-success architecture issue, shows how an earlier lifecycle event can be promoted into a later completion claim. Emitting a request does not prove its destination adopted it. Updating source does not prove the application a person launches has changed.

#90150 brings build transformations, package resolution, native bindings, runtime loaders, and real protocol peers into the system being evaluated. A source-level test is evidence about the source execution path it exercised. A delivered application adds transformations that may change the behavior. The architecture therefore requires evidence at the realization people actually use, linked to the exact-object completion contract.

Why the artifacts are closed-loop

I describe this as a closed-loop series of artifacts because the architectural claim is connected to the records that constrain, challenge, implement, and qualify it. The issue is not left as an isolated essay. Its public comment graph carries bounded, ordered packets with source anchors and captured-body receipts. Its interlock ledger distinguishes closing references from related work. Its property matrix gives failure scenarios explicit expected outcomes.

That structure makes a contradiction locatable. A claimed closure needs a corresponding implementation relationship. A typed result needs the evidence its formation requires. A new boundary must preserve the same authority conditions. A missing relationship remains a visible gap. The artifacts seal the argument by making its obligations inspectable and connected; they do not certify themselves as proof that every implementation has passed.

The August 25 master account enumerates 36 interlock PRs, distinguishes them from 89 broader PR references, and records an unbound core issue and unbound PRs. Those are dated source figures, not current totals or hidden defects removed for presentation. The implementation plan and later S1 publication update also distinguish planned slices from an actual PR carrier. Architectural resolution is the unified correction described here. Complete runtime adoption remains a separate proposition requiring implementation and conformance evidence.

Follow the architecture into the work

The interactive Hermes graph exposes the repository relationships that already carry this programme. Start at the synthesis, select a primitive, and follow its linked incidents and implementation records. Use the participation overview to place that work alongside authorship, discussion, and review.

The same concern for preserved meaning appears in my code reviews, in the independent verification geometry of 5×2×3, and in Godfile decomposition. Those are distinct parts of the work. Together they explain how a repository can become easier to reason about without losing the contracts, evidence, or people that made it function.