---
title: "PROOF-HORIZON SHARDING"
subtitle: "Correction-Surviving, Proof-Carrying Canonical Computation"
author: "Breyden E. Taylor | Founder, Inventor and Architect, Prompted LLC"
date: "Technical Whitepaper 1.1 | Ubiquity Lineage Revision | September 2026"
lang: en-US
---

\newpage

# Publication and lineage notice

**A temporal evidence protocol for parallel verification without parallel authority.**

Copyright (c) 2026 Prompted LLC. All rights reserved.

**Recommended citation.** Taylor, B. E. (2026). *Proof-Horizon Sharding: Correction-Surviving, Proof-Carrying Canonical Computation* (Technical Whitepaper 1.1). Prompted LLC.

**Document status.** This manuscript is the v1.1 publication candidate. It is a from-the-top lineage-corrected rewrite of v1.0. Once admitted by Prompted LLC, v1.1 supersedes the architectural framing of v1.0; v1.0 remains lineage, not authority. This paper is a technical disclosure and architecture paper. It is not a patent opinion or claim-construction document.

> **Core claim.** Proof topology should follow epistemic dependency, not workspace topology. Many humans, agents, machines, clones, and repositories may inspect and prove an evolving system in parallel, while one serial authority advances what the system accepts as canonical.

**Lineage statement.** The broader governed-horizon primitive is inherited from Breyden E. Taylor's Ubiquity architecture at Prompted LLC and its FORKED estate. Proof-Horizon Sharding does not claim to originate horizon geometry. Its distinct contribution is the temporal-evidentiary specialization of horizon noncollapse: the earliest horizon at which a fact can lawfully become knowable becomes the sharding key for proof. From that rule follow exact subject binding, orthogonal proof fan-out, zero-authority verification lanes, governed convergence, descendant evidence carriage, recursive carrier proof, serial canonical admission, correction-surviving lineage, and deterministic re-entry. [1-13]

## Revision 1.1

Version 1.1 makes six material corrections and extensions.

1. It restores the proper intellectual lineage from Prompted LLC and Ubiquity through Fractal Quivers of Quivers, Computing Around the Open Center, and FORKED to PHS.
2. It distinguishes the upstream invention of governed horizon geometry and horizon noncollapse from the PHS-native use of lawful knowability as an evidence partition key.
3. It integrates Prompted LLC's public doctrines of sovereign continuity, Look-First custody, reusable human judgment, parent-gated succession, and projection non-authority.
4. It expands the formal model with an explicit cross-horizon admission relation and derives the no-self-attestation, carrier-recursion, correction-conservation, observer-scaling, and projection-nonauthority results from that relation.
5. It expands the adjacent-work comparison to include SCITT and RATS in addition to Git, in-toto, SLSA, reproducible builds, artifact attestations, and transparency logs.
6. It adds bounded operational evidence from the August 2026 Forge production history while refusing to translate line movement into quality, deployment, adoption, or causal proof.

\newpage

# Contents

| Main sections | Continuation and appendices |
|---|---|
| Abstract | 11. Agentic systems and sovereign continuity |
| Executive statement | 12. Organizational and cross-domain enablement |
| 1. Introduction: assurance after comprehension scale | 13. Security and threat model |
| 2. Lineage, inheritance, and attribution | 14. Relationship to the Ubiquity corpus |
| 3. The temporal self-attestation problem | 15. Relationship to adjacent technical work |
| 4. Design thesis | 16. Operational emergence and bounded empirical context |
| 5. Formal protocol model | 17. Origin, attribution, and invention method |
| 6. Reference epoch | 18. Limitations and open work |
| 7. Protocol invariants | 19. Conclusion |
| 8. Receipt and carrier model | Appendix A. Protocol pseudocode |
| 9. Git reference realization | Appendix B. Reference receipt schema |
| 10. Failure semantics and correction survival | Appendix C. Conformance checklist |
|  | Appendix D. Selected glossary |
|  | Appendix E. Lineage and claim register |
|  | References and acknowledgment |

\newpage

# Abstract

Modern software and agentic systems can generate, inspect, test, and distribute change through many concurrent actors. Their assurance models, however, frequently collapse several different facts into one status such as *green*, *pushed*, *released*, or *done*. A source artifact may exist locally without being available from an intended remote. A push may report success without an independent readback. A test may pass only because the authoring machine contains untracked state. A receipt may describe its predecessor accurately while being unable to prove its own later propagation. When these distinctions are erased, the system permits artifacts to imply knowledge of events that occurred only after those artifacts existed.

Proof-Horizon Sharding (PHS) is a checkpoint protocol derived within the Ubiquity governance substrate and from the horizon-noncollapse doctrine expressed in FORKED. Prompted LLC defines Ubiquity as a governance substrate for sovereign adaptive systems: AI-mediated systems intended to increase capacity without collapsing agency, authorship, judgment, or meaningful contribution. FORKED is an estate inside that parent substrate and makes governed horizon geometry explicit: task, mission, battle, campaign, war, institutional, and other scales retain distinct telos, authority, standing, success and failure conditions, externalities, and irreversible surfaces. A declaration at one horizon does not silently acquire authority at another. [1-5]

PHS specializes that inherited horizon primitive to evidence through time. It partitions verification according to the earliest horizon at which each claim can lawfully become knowable. Canonical mutation remains serial. Verification fans out across zero-authority proof lanes over one immutable subject. Independent observations converge into a descendant receipt or state carrier. That carrier then becomes a new proof subject, preventing it from certifying its own future. Synchronized repositories and refs function as projections of canon rather than parallel canonical authorities.

The resulting primitive is **correction-surviving, proof-carrying canonical computation**: distributed execution, verification, and custody can scale independently while accepted state remains temporally honest, reproducible, auditable, and deterministically resumable. Git is the reference realization, not the boundary of the method. The same geometry can govern any substrate with strongly identified subjects, ordered successor state, independently observable proof surfaces, durable receipts, explicit authority ceilings, and governed convergence.

**Keywords:** Ubiquity; Prompted LLC; FORKED; horizon noncollapse; proof horizon; canonical computation; temporal evidence; checkpoint protocol; agent governance; reproducibility; provenance; Git; distributed verification; serial authority; sovereign continuity.

# Executive statement

> **PHS governs what a system may truthfully say about change after the change becomes too large for ordinary human review to remain the primary control plane.**

The production problem has changed. AI systems can now generate coherent candidate surfaces faster than a human or conventional review team can inspect every line. That does not eliminate the need for human judgment. It changes where judgment must enter. Permanent per-action approval becomes a bottleneck, a rubber stamp, or a blind spot at production throughput. Prompted LLC's Ubiquity architecture therefore treats human judgment as reusable structure: corrections, refusals, approvals, exceptions, rollbacks, and observed outcomes become evidence that can be carried forward instead of being re-asked in every session. [1,8,28]

That answer requires a stronger distinction than human-in-the-loop versus autonomy. It requires an account of what the system knows, when it could know it, who was permitted to establish it, what exact subject the claim concerns, and what stronger interpretations remain unsupported.

The parent matters. Ubiquity is the governance substrate. Fractal Quivers of Quivers supplies a lawful-motion and responsibility topology. Computing Around the Open Center supplies the splat as a bounded, receipt-bearing local compute object that does not crown its working center as universal truth. FORKED specializes those mechanics around observer-indexed reality, suspension, correction, declaration, mission-state integrity, and horizon noncollapse. PHS specializes them again along the temporal-evidentiary axis. The relationship is inheritance, not renaming. [5-7]

The central refusal is simple:

> **No immutable artifact may be treated as evidence of an event that had not occurred when the artifact was created.**

A source-bearing commit can establish that exact source bytes exist. It cannot establish its own later remote propagation. A remote readback can establish that an intended ref exposes the exact subject. It cannot establish independent reproduction. A clean clone can establish acquisition and a declared validation predicate. It cannot establish deployment, adoption, or outcome. A descendant carrier can preserve those observations. It cannot certify its own later propagation. Every stronger claim requires a later lawful edge.

This refusal produces a complete control law:

```text
bounded candidate
-> immutable source subject
-> parallel orthogonal proof lanes
-> governed join
-> descendant receipt carrier
-> carrier becomes next proof subject
-> terminal reconciliation
-> one serial canonical admission path
```

The protocol does not ask one human to read everything. It scales bounded falsification. Many proof workers may inspect the same fixed subject through different failure surfaces. None gains canonical admission authority merely by producing a receipt. Their observations converge only under a declared closure predicate. Evidence classes remain distinct. Failures remain bound to the subjects that failed. Corrections produce new subjects instead of rewriting history. A successor resumes from the first missing proof edge rather than reconstructing intent from a vanished context window.

This is the capability PHS enables:

> **Distributed execution, verification, and custody can scale independently while canonical state remains serial, temporally honest, reproducible, correction-bearing, and deterministically resumable.**

![Figure 1. Intellectual and architectural lineage. PHS inherits Ubiquity's constitutional substrate and specializes FORKED's horizon-noncollapse doctrine along the temporal-evidentiary axis.](figures/figure01_lineage.png){width=88%}

\newpage

# 1. Introduction: assurance after comprehension scale

The dominant coordination problem in high-velocity software is no longer merely how to produce change. It is how to preserve a trustworthy distinction between what has been proposed, what exists, what has been distributed, what has been independently reproduced, what has been admitted, what has been deployed, what has been accepted, and what has actually affected the world.

That problem becomes acute when artificial intelligence increases the number and speed of candidate implementations. A model can generate a large and internally coherent source surface in minutes. Other models can review it, test it, summarize it, or extend it. Yet coherence of output is not evidence of correctness, and multiplicity of reviewers is not a governance model. If every agent can update the state that later agents treat as true, horizontal intelligence scaling becomes horizontal authority scaling. The result is divergent state, ambiguous custody, and reconciliation work that can grow faster than the work itself.

Conventional workflows usually respond in one of two ways. They serialize most activity to preserve consistency, sacrificing throughput; or they parallelize activity through branches, worktrees, repositories, CI jobs, and agents, then attempt to reconstruct one story after the fact. Both approaches tend to conflate where work occurs with when claims about that work can be established.

Prompted LLC frames the larger problem as the shift from answers to outcomes. Once AI participates in real work, the relevant question is not simply whether a model can act. The surrounding system must know when to act, when to hold, when to ask for judgment, what evidence has earned autonomy, and how outcomes should modify later behavior. Ubiquity responds by encoding governance into runtime rather than applying safety only as a post-reasoning wrapper. Signals detect divergence; warrants hold provisional state; rules emerge only when evidence stabilizes. [1,2]

PHS addresses one specific control surface inside that larger substrate: the evidentiary ordering of evolving canonical state.

Its central rule is:

> **Shard proof by temporal attainability and evidentiary scope, not by workspace, actor, branch, or repository.**

A source-bearing subject is first made immutable. Proof lanes then inspect that same subject through different failure surfaces. A direct remote-ref readback answers whether intended distribution surfaces expose the exact subject. An independently acquired detached clone answers whether another environment can acquire and reproduce it without inheriting the authoring machine's residue. Security, schema, lineage, policy, and artifact-integrity predicates may run alongside them. The observations join only after their own predicates pass and only through an actor or mechanism possessing the declared convergence authority.

A descendant carrier may then preserve those observations, but it cannot claim evidence about events that occur after it is created. It must itself become the subject of a later checkpoint. This creates a temporal evidence layer over content-addressed history.

The Git reference implementation therefore contains three related but non-identical graphs:

```text
immutable succession graph
+ proof graph
+ authority graph
= governed checkpoint history
```

Git supplies content-addressed objects, commit parentage, refs, remotes, and clones. PHS supplies the governing relationship among them: which subject a receipt concerns, which evidence horizon the receipt can establish, which actor may emit it, where it may converge, and what later object must carry it. [16-19]

The deepest result is not a better release checklist. It is the ability to coordinate broad parallel reasoning around a bounded serial truth path. In this paper, *truth* means accepted canonical state within an explicitly declared scope. It does not mean metaphysical or universal truth. *Proof* means evidence satisfying a declared predicate for a bounded claim. It does not mean mathematical proof unless explicitly stated.

# 2. Lineage, inheritance, and attribution

## 2.1 Prompted LLC and the Ubiquity parent

Prompted LLC publicly identifies itself as the builder of Ubiquity, a governance substrate for sovereign adaptive systems. It distinguishes this software and logical governance substrate from sovereign cloud, data residency, model hosting, and national AI infrastructure. Its stated aim is to let AI-mediated systems increase capacity without collapsing agency, authorship, judgment, or meaningful contribution. [1-3,12]

The Ubiquity definition of sovereignty is a continuity condition: agency that survives amplification, dependence, complexity, automation, and scale. Autonomy is a runtime mechanism that may be granted, earned, scoped, revoked, audited, or rolled back. Sovereignty is not conferred on a model or tool merely because it can operate independently. The person or institution remains the principal whose agency must remain causally legible. [1,4,12]

PHS inherits five constitutional commitments from that parent substrate.

First, governance must be part of the runtime rather than a label added after the work. Second, human judgment should enter at the edge of earned trust and compound into reusable structure rather than becoming a permanent queue. Third, source, projection, observation, inference, declaration, deployment, adoption, and outcome must retain distinct source-tense and evidence status. Fourth, correction must be carried rather than erased. Fifth, authority must be inspectable and may not be inferred merely from possession of capability or credentials. [1,2,4,8-12]

PHS does not claim these parent mechanics as PHS-only inventions. It uses them to solve a narrower problem: how evidence about an evolving subject can be acquired in parallel without allowing proof workers, mirrors, or later summaries to become parallel sources of canonical truth.

## 2.2 Fractal Quivers of Quivers and lawful motion

*Fractal Quivers of Quivers* (FQoQ) supplies the mathematical substrate behind Ubiquity's living governance topology. A normal directed graph identifies vertices and directed edges. A governed quiver must additionally represent whether an edge is lawful, who has standing and authority to traverse it, what the traversal costs, which receipts it requires, what would halt it, what telos it serves, and how correction remains possible. [6]

PHS inherits that view of state transition. A proof result is not just a Boolean. It is a typed traversal over an exact subject under an authority ceiling, evidence predicate, method, environment, and convergence rule. The protocol's proof graph is therefore a governed quiver narrowed into a checkpoint-specific execution DAG. The quiver preserves recurrence, contradiction, and correction. The DAG discharges a bounded responsibility and terminates.

This matters because a receipt detached from standing and authority can be authentic yet inadmissible. A signed observation may identify its signer and preserve its bytes while remaining outside the lawful traversal set. PHS therefore treats authority admissibility as coequal with temporal and predicate admissibility.

## 2.3 Computing Around the Open Center and splat mechanics

*Computing Around the Open Center* extends the FQoQ substrate into a governance-native compute paradigm. Its splat is a bounded local field that retains positive structure, exclusion, authority, complement, inversion, purpose, unresolved branches, receipts, and renarrow conditions without converting a working centroid into a universal crown. The center remains open while branches may lawfully close. [7]

PHS inherits this anti-capture geometry. A checkpoint is a splat over an exact subject and declared proof horizon. Its predicates can close locally without asserting that the system is universally safe, deployed, adopted, successful, or complete. Terminal reconciliation is a quiet point inside a declared scope, not a claim that no stronger horizon exists.

This is also why PHS receipts require explicit nonclaims. A receipt that says what it proves but not what it excludes leaves an open path for later actors to promote local closure into a stronger domain. Nonclaims are not cautious prose. They are executable perimeter.

## 2.4 FORKED and governed horizon geometry

FORKED v2.0 is the direct horizon-lineage parent of PHS. It is authored by Breyden E. Taylor as Inventor and Architect at Prompted LLC and explicitly identifies itself as an estate inside the Ubiquity Federation rather than the parent itself. At the access date, Prompted LLC's public Atrium and FORKED surface identify FORKED v2.0 as the current foundational head; the papers registry records its foundational status, authorship, version, source pins, and relationships to FQoQ and Computing Around the Open Center. [1,5,13]

FORKED makes horizon geometry first-class. Task, mission, battle, campaign, war, strategic, institutional, civilizational, and other scales remain separate quivers. Each may carry different telos, authority, standing, success and failure definitions, valid time, resource envelopes, acceptable loss, irreversible surfaces, dependencies, observer geometry, and correction obligations. [5]

Its horizon-noncollapse lemma states, in substance, that a declaration at horizon h1 cannot acquire authority at horizon h2 without an admitted typed cross-horizon edge carrying the required standing, externality accounting, evidence, and authority. Task success cannot silently become mission success. A locally green component cannot silently crown a globally red system. A local implementation receipt cannot become human, field, hardware, customer, or operational evidence merely because the synthetic lane is large. [5]

That is the horizon invention upstream of PHS.

## 2.5 PHS as temporal-evidentiary specialization

PHS asks a narrower question than FORKED's general horizon geometry:

> **At what earliest horizon can this exact fact lawfully become knowable, through which independent surface, and what later object may truthfully carry that observation?**

The answer becomes the sharding key for proof.

If source bytes have not yet been materialized into an immutable subject, no later remote or reproduction claim is available. Once the subject exists, remote propagation and clean acquisition may be observed independently. Those observations cannot appear in the original subject because they occur later. A descendant carrier is required. The descendant's own later propagation is unavailable at its creation, so it must become the next proof subject. Carrier recursion is therefore not an optional ceremony. It follows from horizon noncollapse plus causal order.

PHS is thus neither a renaming of Ubiquity nor a replacement for FORKED. Ubiquity supplies the constitutional substrate. FQoQ supplies lawful-motion topology. Computing Around the Open Center supplies bounded splat mechanics and center exclusion. FORKED supplies governed horizon geometry and horizon noncollapse. PHS derives a temporal evidence protocol from those inherited constraints.

## 2.6 Canonical attribution and originality boundary

**Canonical attribution:**

> **Breyden E. Taylor designed Proof-Horizon Sharding as a temporal-evidence specialization of the governed-horizon and authority-noncollapse mechanics developed in the Ubiquity architecture and expressed through FORKED. PHS partitions checkpoint verification by the earliest horizon at which a fact can lawfully become known, fans an immutable subject into bounded proof shards, converges those observations into a descendant carrier, recursively checkpoints that carrier, and preserves one serial path for canonical admission.**

The invention includes the temporal self-attestation problem framing, the lawful-knowability partition rule, fixed-subject orthogonal proof fan-out, zero-authority proof lanes, governed fan-in, descendant evidence carriage, recursive carrier proof, projection non-authority, correction-conservation result, and deterministic proof re-entry.

PHS does not claim invention of Ubiquity's full governance substrate; governed horizons as a general concept; FQoQ; splat mechanics; the open-center doctrine; FORKED's broader mission-horizon geometry; Git; commits; branches; worktrees; remotes; clones; attestations; provenance; transparency logs; or single-writer systems as isolated primitives.

The attribution discipline follows the same inheritance rule FORKED applies to itself: an inheriting estate or paper must preserve parentage without claiming the parent as a native invention. [5]

# 3. The temporal self-attestation problem

## 3.1 A checkpoint is usually several events disguised as one

A typical repository workflow may say that a change is complete after a commit is made, tests pass, and a push succeeds. That sentence contains several distinct events:

- source bytes exist in a mutable working directory;
- those bytes are selected for admission;
- the selection is represented by an immutable object;
- an exact subject identity exists;
- one or more target surfaces accept an update request;
- named remote refs expose the exact identity;
- another environment can acquire the exact identity;
- the acquired state passes declared validations;
- observations about these facts are durably recorded;
- the record carrying those observations is itself distributed and reproducible;
- an authorized process admits the checkpoint as closed;
- a runtime is changed;
- the runtime exposes the admitted version;
- a stakeholder accepts the result;
- the intended real-world outcome occurs.

No single event proves all the others. A local test does not prove remote availability. A successful push operation does not prove direct remote readback. A remote-tracking ref may show only the state observed during prior communication. A detached reproduction does not prove deployment. A deployment readback does not prove adoption. Outcome evidence cannot be inferred from repository state at all. [16-19]

The problem is not merely that evidence may be missing. The deeper problem is that a workflow may place claims into artifacts that could not have known those claims when they were created.

## 3.2 Immutable artifacts cannot know their own future

Let x be an immutable artifact created at time t(x). Let e be an event concerning x, such as propagation, independent acquisition, execution, acceptance, or outcome. If t(e) > t(x), then x cannot truthfully contain an observation of e as part of its original immutable content.

For Git commits, the issue is concrete. A commit object contains a tree, parent references, author and committer data, timestamps, and a message; its identity is derived from the serialized object. The final identity exists only after construction. Remote propagation and independent reproduction occur later still. A source-bearing commit therefore cannot be the truthful carrier of observations about its own later remote state or clone reproduction. [16]

A later descendant can carry those observations. But the descendant has the same limitation regarding its own future. If that carrier is later pushed, read back, cloned, reproduced, signed, deployed, or accepted, those observations must be carried by a still later artifact or a durable external log whose causal relation is explicit.

This recursive boundary is the temporal self-attestation problem:

> **No immutable artifact may be treated as evidence of an event that had not occurred when the artifact was created.**

PHS turns the boundary into the architecture.

## 3.3 False closure is a category and horizon error

| Collapsed statement | What it may actually establish | What it does not establish |
|---|---|---|
| "Committed" | Source exists in a local immutable object | Remote availability, reproducibility, deployment |
| "Pushed" | A client reported an update attempt or success | Direct remote-ref parity, independent retrieval |
| "CI green" | Declared checks passed in one configured environment | Clean acquisition, complete predicate coverage, outcome |
| "Mirrored" | Another repository may contain equivalent objects or refs | Equal authority, current parity, lawful custody |
| "Released" | A tag or publication event occurred | Reproducibility, deployment, adoption, business outcome |
| "Receipt written" | A record exists | Accuracy, authenticity, carrier propagation, closure |
| "Deployed" | A change operation targeted a runtime | Runtime readback, user exposure, acceptance, outcome |
| "Adopted" | Some use or acceptance was observed | Sustained use, benefit, mission success, causal outcome |

The protocol therefore treats source, identity, distribution, reproduction, evidence carriage, carrier proof, deployment, adoption, and outcome as separate horizons. A stronger claim requires a stronger horizon and an admitted cross-horizon edge. It cannot be obtained by renaming a weaker receipt.

## 3.4 Provenance is necessary and insufficient

Provenance can establish ancestry, materials, process, identity, signer, or chain of custody. It does not by itself establish semantic truth, fitness, lawful authority, complete predicate coverage, or real-world outcome. FORKED makes this distinction explicit in its source-tense discipline, and modern attestation standards preserve related boundaries. [5,20-27]

PHS therefore separates four questions that are often collapsed:

1. **Authenticity:** are these the bytes or claims signed by the identified actor?
2. **Accuracy:** did the reported observation occur as stated?
3. **Independence:** what authoring state, trust root, host, account, or organization was not inherited?
4. **Admissibility:** did the actor possess the authority and standing required for this result to enter canonical closure?

A cryptographically authentic lie remains a lie. An accurate observation from an unauthorized actor remains potentially useful evidence but not necessarily admissible canonical state. An independent reproduction may be strong evidence of portability while proving nothing about deployment or impact.


# 4. Design thesis

## 4.1 Proof topology follows epistemic dependency

Branches, worktrees, containers, machines, and repositories answer spatial and operational questions: where can work be performed, and which mutable environments can be isolated? PHS answers an epistemic and governance question: when can a fact become knowable, through which independent surface, and what later object may lawfully carry it?

These are different partition schemes. A branch may host candidate source before an immutable subject exists. A worktree may isolate mutable execution without adding independent evidence. Two proof shards may run in separate machines, organizations, or agents while remaining part of one checkpoint because they inspect the same subject and converge under one authority. Conversely, two tasks in the same process may belong to different proof horizons because one concerns local source identity and another concerns later external state.

The partition axis is therefore lawful knowability.

## 4.2 Horizon noncollapse becomes evidence noncollapse

Let H be a set of governed horizons. FORKED's parent rule can be written abstractly as:

```text
Admit_h2(q) =>
  Claim_h1(q)
  AND CrossEdge(h1, h2, q)
  AND Standing_h2
  AND Authority_h2
  AND Externalities_h2
```

where a claim established at horizon h1 may enter h2 only through a typed cross-horizon edge carrying the requirements of h2.

PHS specializes that relation. For an exact subject S and claim q, define the lawful knowledge horizon:

```text
H*(q, S) = earliest h in H such that q can be directly observed
           about S under the declared method, standing, and authority
```

The claim may not be admitted below H*(q,S), because the relevant fact does not yet exist or cannot yet be observed. It may not be promoted above H*(q,S) without another typed edge and stronger evidence.

This makes evidence noncollapse a direct corollary of horizon noncollapse.

## 4.3 Parallel assurance without parallel authority

PHS distinguishes three powers:

- **Proposal:** the ability to produce candidate state.
- **Observation:** the ability to inspect a subject and emit a bounded receipt.
- **Admission:** the ability to advance accepted canonical state.

Many actors may propose. Many may observe. Only the designated canonical lane may admit.

A proof worker does not need write authority over canon. It needs an exact subject, a declared proof horizon, a permitted evidence surface, a predicate, a receipt schema, an authority ceiling, a stop condition, and a convergence destination. This creates a zero-authority proof lane: a worker may inspect and report but cannot silently convert its observation into accepted state.

The number of observers can therefore grow without increasing the number of canonical writers.

## 4.4 Projection is not authority

A repository, ref, cache, binder, report, or natural-language rendering may carry an exact copy or bounded expression of canonical state for continuity, disaster recovery, organizational projection, external verification, migration readiness, or human legibility. Possession of state does not confer authority to originate accepted transitions.

PHS treats synchronized refs and repositories as canonical projections. They may be acquisition surfaces and proof targets. They may be maintained in exact parity. They do not independently decide what becomes canon.

This avoids an unnecessary consensus problem. The system does not ask several repositories to vote on truth. It asks one authority to serialize accepted mutation and several surfaces to preserve and expose the resulting state.

The rule is consistent with the Ubiquity successor topology: implementation bodies may change while ownership, purpose, root identity, telos, invariants, scars, proofs, and attribution remain continuous. External or sibling artifacts may supply provenance without receiving standing in the root lineage. [11,12]

## 4.5 Evidence classes remain distinct at convergence

Proof shards converge without being flattened. A remote-ref receipt and a detached-clone reproduction receipt may jointly support closure, but they remain different evidence types. Their subjects, methods, environments, timestamps or causal positions, limitations, and failure surfaces remain visible.

This matters because evidence is often weakened during summary. PHS makes summary downstream of receipts rather than a substitute for them. A join may assert that the declared closure predicate is satisfied. It may not erase which receipt supported which proposition.

![Figure 2. Governed checkpoint history overlays immutable succession, independent proof, and explicit authority.](figures/figure02_governed_history.png){width=88%}

# 5. Formal protocol model

## 5.1 Core entities

A PHS epoch contains the following entities.

| Symbol | Entity | Meaning |
|---|---|---|
| S | Subject | An immutable or strongly identified object under proof |
| id(S) | Subject identity | A content address, digest, revision ID, or equivalent stable identifier |
| h | Proof horizon | The strongest bounded claim class currently supportable |
| P_i | Proof shard | An independently executable predicate over S |
| R_i | Receipt | A durable record of subject, method, observation, result, and limitation |
| K | Carrier | A descendant object that durably incorporates valid receipts about a predecessor |
| A_i | Authority ceiling | The strongest action or claim permitted to a lane or actor |
| J | Join | The controlled convergence of required proof shards |
| Gamma | Closure predicate | The complete conditions required to close the declared epoch |
| X | Cross-horizon edge | A typed transition admitting a proposition from one horizon to another |
| C | Canonical lane | The single ordered path through which accepted state advances |

A receipt is always about an exact subject. It does not float freely as a statement that "the project passed." If source changes, the subject identity changes, and proof must be evaluated against the new subject.

## 5.2 Temporal admissibility

A receipt R_i about subject S is temporally admissible to carrier K only when:

```text
t_create(S) <= t_observe(R_i) < t_create(K)
```

The first relation requires the subject to exist before it is observed. The second requires the observation to exist before a carrier claims to preserve it. If R_i concerns propagation, retrieval, reproduction, execution, or acceptance of K, it cannot be contained by K. Another carrier or durable external log is required.

The protocol may use clocks, signed timestamps, transparency logs, monotonic sequence numbers, repository ancestry, trusted execution evidence, or combinations of these to support ordering. The abstract requirement is causal order, not dependence on one clock implementation.

## 5.3 Predicate admissibility

A receipt is predicate-admissible only when:

```text
R_i.subject = id(S)
AND R_i.method in M_i
AND R_i.result in {pass, fail, held, indeterminate, not_applicable}
AND R_i.evidence satisfies P_i(S)
```

where M_i is the allowed method set for the proof shard.

A passing receipt means only that the declared predicate passed under the declared method and environment. It does not imply completeness of the predicate, universal validity, or fitness beyond its scope.

## 5.4 Authority admissibility

A transition is authority-admissible only when the actor's authority ceiling contains the requested action:

```text
RequestedAction(a) <= AuthorityCeiling_i(a)
```

A lane with observe-and-receipt authority may run a predicate and produce a receipt. It may not update the canonical ref. A projection maintainer may synchronize an already authorized subject to a target surface but may not select a different source subject. A human reviewer may possess admission authority for one scope without possessing deployment or outcome-declaration authority.

Authority is explicit metadata and executable policy, not an inference from access possession.

## 5.5 Cross-horizon admissibility

A claim q may move from h1 to h2 only when a typed edge X(h1,h2,q) is admitted:

```text
AdmissibleCross(q, h1, h2) =
  EvidenceBound(q, S)
  AND StandingValid(h2)
  AND AuthorityValid(h2)
  AND ExternalitiesAccounted(h2)
  AND NonclaimsPreserved(q)
```

This relation prevents horizon laundering. A repository receipt cannot become a deployment receipt through prose. A deployment receipt cannot become an adoption claim because the artifact is impressive. A synthetic campaign cannot become field evidence by scale.

## 5.6 Closure

An epoch closes when every required shard has a valid receipt, every receipt is bound to the declared subject or lawful successor, every temporal relation is lawful, every actor remained within its authority ceiling, the carrier preserves the required observations, all required carrier proofs passed, and the terminal state agrees with the declared convergence target.

Informally:

```text
Close(epoch) =
  all required predicates passed
+ all receipts match exact subjects
+ all temporal relations are lawful
+ no authority ceiling was exceeded
+ required cross-horizon edges were admitted
+ the carrier is admitted
+ all required carrier proofs passed
+ terminal pointers reconcile
```

Closure is scoped. Repository closure does not imply deployment closure. Deployment closure does not imply adoption closure. Adoption closure does not imply outcome closure.

## 5.7 Governed checkpoint history

The resulting history overlays three structures:

```text
immutable succession DAG
+ proof DAG
+ authority DAG
= governed checkpoint history
```

The succession graph answers what immutable states succeeded one another. The proof graph answers what was observed about which subject and by what path. The authority graph answers who or what was permitted to propose, observe, carry, synchronize, admit, deploy, accept, or declare each transition.

## 5.8 Derived results

### Lemma 1: No self-attestation

For immutable S and event e, if t(e) > t_create(S), then S cannot contain a truthful original observation of e.

**Reason.** The bytes determining id(S) were fixed before e occurred. Adding an observation of e would create a different artifact S'. Therefore the proposition belongs to a later carrier or external evidence surface.

### Corollary 1: Carrier recursion

If carrier K preserves observations about predecessor S and later events concerning K matter to closure, K must become a new proof subject.

**Reason.** By Lemma 1, K cannot contain original observations of its own later propagation or reproduction. A successor carrier or external log is required.

### Proposition 1: Observer scaling without writer scaling

Let n be the number of independent proof workers and let canonical mutation remain one ordered path. Subject to dependency, resource, and join constraints, proof throughput may increase with n without increasing canonical writer count.

This is a topological claim, not a claim of infinite physical capacity. Compute, network, human attention, predicate cost, and join latency remain finite.

### Proposition 2: Correction conservation

If subject S fails predicate P and corrected source produces S', the failure receipt remains bound to S. It cannot be rewritten as a passing receipt for S'. Proof for S' begins on a new path.

The history therefore preserves both the failed subject and the correction edge. This is correction conservation: the system may move forward without laundering the predecessor.

### Proposition 3: Projection nonauthority

If projection Q possesses bytes equivalent to canonical subject S but lacks admitted canonical-write authority, Q cannot originate an accepted successor solely by possession of S.

State equivalence does not imply jurisdictional equivalence.

### Proposition 4: Finite re-entry

If an interrupted epoch durably records its subject, completed shards, pending shards, authority ceilings, predicates, and convergence target, the next lawful action is the minimal unproven predecessor of closure.

Uncertainty is therefore represented as a missing edge rather than a vague status or private-memory dependency.

# 6. Reference epoch

A minimal PHS epoch expands a vague checkpoint into six truth-bearing horizons:

```text
H0   candidate/source disposition
H1   immutable source identity
H2a  remote propagation proof
H2b  independent reproduction proof
H3   durable receipt/state-carrier materialization
H4   carrier propagation/reproduction proof
H5   terminal governed reconciliation
```

The H2 shards may execute concurrently because they inspect one fixed subject through orthogonal failure surfaces. H3 cannot precede them because it carries their observations. H4 cannot be compressed into H3 because the carrier's own final identity and later remote state do not exist until after H3 is created.

![Figure 3. Proof-Horizon Sharding reference epoch.](figures/figure03_reference_epoch.png){width=72%}

## 6.1 H0 - Candidate disposition

The epoch begins with a bounded candidate. The system records its scope, origin, intended effect ceiling, admission requirements, dependencies, externalities, and nonclaims. H0 answers whether the candidate is rejected, held, corrected, or eligible to become a source subject. It does not yet provide immutable source identity.

A candidate may come from a human, an AI agent, a branch, a patch, a generated package, a database plan, a signed policy, or another repository. PHS is neutral to authorship method. What matters is that candidate generation is not mistaken for admission.

H0 is also where the parent horizon is declared. A candidate proposed for repository-source admission does not thereby possess deployment, stakeholder-send, financial, legal, or outcome authority.

## 6.2 H1 - Source-bearing subject

The accepted source tranche is materialized into an immutable or strongly identified subject. In Git, this is the source-bearing commit. Its object ID and tree identity become the fixed binding for later proof.

H1 establishes that selected source exists. It does not establish that a remote exposes it, that another environment can acquire it, that it can execute without authoring residue, or that it is deployed.

## 6.3 H2a - Distribution proof

A distribution proof reads the intended target surface directly and verifies that each required ref or object endpoint exposes id(S). In the Git profile, direct remote-ref readback is stronger than trusting a local remote-tracking ref because the latter reflects the remote as of the last network communication. [17]

The receipt should identify every expected remote and ref, the observed object ID, the observation time or causal position, the comparison predicate, and any unreachable or ambiguous target.

H2a proves distribution within the declared target set. It does not prove clean acquisition, execution, deployment, or acceptance.

## 6.4 H2b - Independent reproduction proof

A reproduction proof acquires the exact subject through an intended distribution surface into an environment that does not inherit undeclared mutable state from the authoring checkout. In the Git profile, a disposable clean clone checks out the exact commit in detached state and runs declared validations.

This lane detects dependencies hidden by the authoring environment, including:

- untracked or ignored files;
- stale generated artifacts;
- local-only configuration;
- undeclared dependencies;
- machine-specific caches;
- unavailable hooks or scripts;
- hidden symlinks;
- objects present locally but absent from the intended remote;
- tests that pass only because of prior local execution.

The distinction is between "the authoring environment can execute this" and "an independently acquired exact subject can satisfy the declared predicate."

H2b proves only the declared reproduction predicate. It does not necessarily prove bit-for-bit build reproducibility unless that stronger condition is explicitly required. [22]

## 6.5 H3 - Receipt/state carrier

After all required H2 shards pass, their observations converge into a descendant carrier. The carrier preserves:

- exact predecessor subject identity;
- proof-horizon labels;
- predicates, methods, and results;
- observer and environment descriptors;
- observation times or causal positions;
- authority ceilings;
- evidence bindings;
- limitations and explicit nonclaims;
- join status;
- correction links;
- next required horizon.

The carrier may be a commit, signed attestation bundle, append-only log entry, governed database record, executed policy packet, or another durable object.

H3 makes evidence durable. It does not prove the carrier's own later propagation.

## 6.6 H4 - Carrier checkpoint

The carrier becomes the next subject. The system performs whatever distribution, retrieval, reproduction, signature, or transparency checks policy requires for that carrier.

This is the recursive move that prevents self-certification. Carrier recursion may continue for several layers when assurance domains are separated. One carrier may preserve repository evidence. A later carrier may preserve deployment evidence. Another may preserve stakeholder acceptance. Each artifact claims only within its temporal and semantic horizon.

## 6.7 H5 - Terminal reconciliation

Terminal reconciliation confirms that source, proof, carrier, projections, execution pointers, and checkpoint state agree with the declared closure predicate. Any ordinary work graph, task tracker, release pointer, or operational status may advance only to the horizon actually earned.

The system reaches a quiet point when no unresolved residue remains inside the claimed scope. A quiet point does not claim that the system is permanently complete. It claims that the declared epoch contains no hidden pending edge.

# 7. Protocol invariants

PHS is defined less by a command sequence than by invariants every implementation must preserve.

| ID | Invariant | Required property |
|---|---|---|
| I1 | Exact subject binding | Every receipt names one immutable or strongly identified subject |
| I2 | Horizon noncollapse | Standing or evidence at one horizon does not silently become standing or evidence at another |
| I3 | Serial canonical mutation | Accepted state advances through one ordered logical authority path |
| I4 | Proof-authority separation | Proof workers cannot silently admit their own observations into canon |
| I5 | Temporal admissibility | A carrier may contain only observations available before its creation |
| I6 | No self-attestation | An artifact cannot certify its own future propagation, retrieval, execution, acceptance, or outcome |
| I7 | Evidence-class preservation | Distribution, reproduction, deployment, adoption, and outcome receipts are not interchangeable |
| I8 | Independent acquisition | Reproduction proof must not inherit undeclared mutable authoring state |
| I9 | Projection non-authority | Synchronized copies do not become coequal canonical writers merely by possessing state |
| I10 | Subject-relative monotonicity | Later carriers add bounded observations without rewriting what earlier subjects could know |
| I11 | Correction survival | Failed, corrected, and superseded attempts remain intelligible in lineage |
| I12 | Deterministic resumption | A successor can identify the first required unproven horizon without reconstructing intent from memory |
| I13 | Scoped closure | A closed horizon may not be promoted into a stronger domain without new evidence |
| I14 | Source-tense preservation | Source, observation, inference, declaration, execution, adoption, and outcome retain distinct tense and status |
| I15 | Explicit nonclaims | Every receipt preserves the stronger interpretations it does not support |
| I16 | Lawful cross-horizon admission | Cross-horizon movement requires a typed edge with standing, authority, evidence, and externality accounting |
| I17 | Look-First custody | An actor reattaches to current canonical state before authoring an overwrite or successor transition |
| I18 | Human judgment at earned-trust edges | Human intervention is placed where novelty, consequence, shallow evidence, or authority ambiguity requires it and is carried forward as governed evidence |

## 7.1 Monotonicity is subject-relative

PHS evidence is monotonic with respect to an exact subject: a later receipt may add observations about S without changing S or erasing prior receipts. If source changes produce S', receipts about S do not migrate. The new subject begins a new proof path.

A failed receipt therefore remains true as a record that a particular predicate failed at a particular time or causal position. Correction does not require narrative erasure.

## 7.2 Independence is declared, not assumed

"Independent" must be defined by policy. A new directory on one machine may detect untracked files but not organizational collusion. A container may isolate dependencies while sharing a compromised host. A separate cloud account may still share credentials or build provenance. High-assurance profiles may require independent operators, hosts, hardware roots, organizations, implementations, or legal custodians.

The receipt must state the independence boundary it actually proves.

## 7.3 Look-First is custody, not permission

Prompted LLC's Look-First doctrine requires an actor to reattach to canonical state before acting on or overwriting it. The read is not a ceremonial permission check. It is how the actor takes custody of what the action will unmake and what it will construct in the same transition. [10]

PHS adopts Look-First at every subject-selection and correction boundary. A successor cannot lawfully claim to preserve lineage it did not inspect. The requirement is especially important when a correction replaces a large state surface: the new subject must name what it supersedes, what remains inherited, and which proofs do not transfer.

# 8. Receipt and carrier model

## 8.1 Minimal receipt

A minimal PHS receipt should be machine-readable and human-auditable. The following substrate-neutral schema is illustrative.

```json
{
  "protocol": "proof-horizon-sharding/v1.1",
  "checkpoint_id": "phs-2026-09-03-001",
  "subject": {
    "type": "git-commit",
    "id": "3786e31ec5d95335d26207e2f0f1cfebda509f14",
    "tree_id": "<tree-object-id>",
    "predecessor": "<optional-predecessor-id>"
  },
  "horizon": "H2b.independent-reproduction",
  "parent_horizon": "repository-source",
  "predicate": {
    "name": "detached-clone-validation",
    "command_manifest": "sha256:<digest>",
    "expected": "all required checks pass"
  },
  "observer": {
    "actor_id": "<verifier-id>",
    "environment_id": "<environment-id>",
    "independence_level": "clean-clone-separate-directory",
    "acquisition": "clone-from-declared-remote"
  },
  "observed_at": "2026-09-03T23:42:18Z",
  "result": "pass",
  "evidence": [
    {"type": "log", "digest": "sha256:<digest>"},
    {"type": "test-report", "digest": "sha256:<digest>"}
  ],
  "authority_ceiling": "observe-and-receipt",
  "nonclaims": [
    "does not prove deployment",
    "does not prove adoption",
    "does not prove business outcome"
  ],
  "convergence_target": "H3.receipt-carrier",
  "next_horizon": "H3.receipt-carrier"
}
```

The schema may be wrapped in in-toto statements, DSSE envelopes, SLSA predicates, SCITT signed statements and receipts, OCI attestations, signatures, or transparency-log entries. These systems can carry PHS evidence, but PHS additionally specifies horizon partitioning, recursive carrier proof, serial admission, cross-horizon noncollapse, and convergence semantics. [20,21,25]

## 8.2 Required semantic fields

Regardless of encoding, a PHS receipt requires the following semantic fields:

1. **Subject:** exact identity and type.
2. **Predecessor or correction relation:** where the subject sits in succession and correction lineage.
3. **Proof horizon:** the claim class being evaluated.
4. **Parent horizon:** the broader jurisdiction in which the proof is requested.
5. **Predicate:** the testable closure condition.
6. **Method:** how the observation was obtained.
7. **Observer:** the actor or system responsible for the observation.
8. **Environment and independence level:** enough information to understand what state was and was not inherited.
9. **Observation time or causal position:** when the fact became available.
10. **Result:** pass, fail, held, indeterminate, or not applicable.
11. **Evidence bindings:** hashes or references to logs, artifacts, and reports.
12. **Authority ceiling:** what the observer was permitted to do.
13. **Standing:** why the observer or authority is relevant to the declared horizon.
14. **Nonclaims:** stronger interpretations explicitly excluded.
15. **Convergence target:** where a passing receipt may lawfully join.
16. **Next horizon:** the first remaining required proof edge.

## 8.3 Receipt authenticity and receipt truth

Cryptographic signatures can establish that a named key signed a receipt and that the bytes have not changed. They do not by themselves establish that the semantic claim is true. PHS separates authenticity, accuracy, independence, standing, and authority.

A high-assurance implementation may combine signed receipts, protected identity, reproducible commands, trusted execution, independent observers, transparency logs, and organizational separation. Rekor can strengthen availability and non-repudiation; SCITT can register signed statements and issue receipts; RATS can structure evidence appraisal among attesters, verifiers, and relying parties. None eliminates the need to declare what exact claim class has been earned. [24-27]

## 8.4 Join receipt

A governed join should emit its own receipt. The join receipt records:

- the fixed subject;
- required shard set;
- each receipt identity and digest;
- required versus optional shards;
- pass, fail, held, or indeterminate state;
- any conflict among evidence classes;
- the authority that evaluated convergence;
- the carrier identity created from the join;
- the next open horizon.

The join is not a summary that replaces its inputs. It is a durable statement that the required inputs were inspected under a declared rule.

## 8.5 Carrier chain

A carrier chain can be represented as:

```text
S0  source subject
 |-- R_remote(S0)
 |-- R_clone(S0)
 |-- R_security(S0)
 v
K1  repository evidence carrier
 |-- R_remote(K1)
 |-- R_clone(K1)
 v
K2  carrier-checkpoint closure
 |-- R_deploy(K2)
 v
K3  deployment evidence carrier
 |-- R_accept(K3)
 v
K4  acceptance evidence carrier
```

Each carrier can support claims about predecessors that existed before it. None may certify its own future. The chain may stop when the declared closure horizon is satisfied; it need not continue indefinitely.

# 9. Git reference realization

## 9.1 Why Git is a useful substrate

Git provides content-addressed objects, commit objects binding trees and parents, an ordered commit DAG, movable refs over immutable objects, direct remote-ref inspection, multiple remotes and repositories, clean-clone acquisition, detached checkout of exact subjects, notes, tags, and optional signatures. [16-19]

Its object database and parentage provide strong subject identity and ordered succession. Remote refs provide independently readable distribution surfaces. Clean clones reveal whether the exact state can be acquired without inheriting the authoring checkout's residue.

Git does not itself provide PHS. Branch names do not establish authority. Notes do not establish horizon semantics. A green workflow does not define closure. PHS supplies those relationships.

## 9.2 Reference mapping

| PHS concept | Git realization |
|---|---|
| Immutable subject | Commit object ID, optionally paired with tree ID |
| Canonical lane | Designated root main under explicit write policy |
| Candidate lane | Patch, branch, worktree, generated tranche, or external repository |
| Distribution proof | Direct readback of expected remote refs against exact commit ID |
| Reproduction proof | Fresh clone from intended remote, detached checkout, declared validations |
| Receipt carrier | Descendant commit containing machine-readable receipts and lineage |
| Projection | Synchronized nonauthoritative ref in another remote or repository |
| Carrier proof | Readback and reproduction of the receipt carrier itself |
| Terminal reconciliation | Canonical pointer, work graph, and checkpoint state agree on closed horizon |

## 9.3 Illustrative command geometry

The following shell is explanatory, not a universal implementation.

```bash
# H1 - select exact immutable subject
SUBJECT="$(git rev-parse HEAD)"
TREE="$(git rev-parse "${SUBJECT}^{tree}")"

# H2a - publish through governed synchronization, then read the target directly
# A production profile should route the write through protected policy.
git push origin "${SUBJECT}:refs/heads/main"
REMOTE_SUBJECT="$(git ls-remote origin refs/heads/main | awk '{print $1}')"
test "${REMOTE_SUBJECT}" = "${SUBJECT}"

# H2b - independently acquire and reproduce the exact subject
TMP="$(mktemp -d)"
git clone --no-checkout "<declared-remote-url>" "${TMP}/repro"
git -C "${TMP}/repro" checkout --detach "${SUBJECT}"
"${TMP}/repro/scripts/validate-checkpoint"

# H3 - create a descendant carrier from the resulting receipts
# The carrier cannot yet prove its own subsequent remote state.
```

A production implementation should verify authorization and fast-forward requirements, protect canonical refs, hash command manifests and outputs, preserve failure receipts, avoid secret leakage, and separately checkpoint the receipt carrier.

## 9.4 Multi-remote projection without canon fragmentation

An implementation may synchronize several refs across several repositories to one selected commit while retaining one canonical writer. These refs provide distribution, continuity, and custody surfaces. They do not become independent authoring lanes merely because each is named `main` or can technically receive writes.

The authority assignment is external to the branch name. `main` is only a ref until governance gives one instance canonical meaning.

## 9.5 Proof-qualified release

A repository release can be defined as a closed set of horizons rather than a tag or CI status:

```text
source admitted
+ exact commit selected
+ required remote refs confirmed
+ clean clone acquired
+ declared validations passed
+ receipt carrier admitted
+ carrier checkpointed
= repository release horizon closed
```

Deployment, adoption, and outcome remain successor horizons.

## 9.6 The pull request is not the invariant

PHS does not prohibit pull requests. It refuses to treat them as the universal unit of governance. A pull request can host proposal, discussion, and review, but its existence does not establish exact remote parity, clean acquisition, carrier propagation, deployment, or outcome.

At machine-scale throughput, line-by-line human review may cease to be physically plausible as the primary assurance mechanism. The lawful replacement is not unreviewed confidence. It is bounded, subject-specific falsification with explicit authority, durable receipts, human judgment at consequential edges, and one governed admission path.


# 10. Failure semantics and correction survival

## 10.1 Faults remain localized

When a checkpoint fails, PHS identifies the failed proof horizon rather than collapsing the event into "release failed."

| Failed horizon | Meaning | Narrow response |
|---|---|---|
| H0 admission | Candidate is invalid, out of scope, unauthorized, or insufficiently bounded | Correct, reject, or hold the candidate |
| H1 source | Immutable source could not be lawfully materialized | Repair source or admission procedure |
| H2a distribution | Expected target does not expose the exact subject | Repair authorization, reachability, ref selection, or propagation |
| H2b reproduction | Independent environment cannot acquire or validate the subject | Remove hidden dependencies or correct source |
| H3 carrier | Receipt bundle is malformed, incomplete, conflicting, or unauthorized | Reconstruct the carrier without reopening valid source proof |
| H4 carrier proof | Carrier exists but its required propagation or reproduction remains open | Checkpoint the carrier as the current subject |
| Deployment horizon | External runtime does not match the admitted artifact | Inspect the deployment path rather than rewriting repository history by default |
| Acceptance horizon | Named stakeholder did not accept or could not inspect the deliverable | Preserve the delivery state and repair the acceptance surface |
| Outcome horizon | Real-world effect is absent, adverse, or unmeasured | Gather outcome evidence or reopen policy without laundering source or deployment receipts |

Fault localization reduces unnecessary rollback. A remote-readback failure does not invalidate a source predicate that genuinely passed. A malformed carrier does not require regeneration of valid source proof. A deployment mismatch does not justify rewriting repository history unless the source itself is wrong.

## 10.2 Corrections produce new subjects

Suppose detached-clone reproduction of source commit C fails because an undeclared file was required. The failure receipt remains bound to C. Corrected source becomes C'. Remote and reproduction proof must be repeated for C'. The system does not edit the record to pretend that C passed.

```text
C   source subject
|-- R_remote(C) = pass
|-- R_clone(C)  = fail
|
C'  corrected source subject
|-- correction_of = C
|-- R_remote(C') = pass
|-- R_clone(C')  = pass
|
K   carrier for C' receipts
```

The scar is useful. It distinguishes source failure from distribution failure, reveals the corrected dependency, and prevents later actors from inheriting a false narrative of uninterrupted success.

This is the PHS expression of a broader Ubiquity commitment: contradiction is not governance failure when the system can preserve, metabolize, and use it to change trajectory. It becomes theater only when the system holds the old account against better evidence.

## 10.3 Deterministic re-entry

At any interruption, a successor resumes from:

```text
exact subject
+ completed proof shards
+ pending proof shards
+ authority ceiling
+ receipt predicates
+ correction links
+ convergence target
```

The next action is the minimal unproven predecessor of closure. The successor does not need the previous agent's context window, terminal scrollback, private memory, or prose summary. This is finite re-entry: uncertainty is represented as a missing edge rather than a vague status.

Deterministic re-entry is not merely a convenience. It is the mechanism by which agent identity, model vendor, machine, worktree, or context window may change without forcing the system to reconstruct intent from narrative residue.

## 10.4 Correction debt

A state accepted before adequate proof creates correction debt. That debt is the downstream burden of locating dependents, restoring source-tense, repairing projections, re-running predicates, notifying affected actors, and distinguishing what remains valid from what has been superseded.

PHS does not claim to eliminate correction debt. It makes the debt visible and subject-bound. Early admission of weakly proved state may still be lawful when delay is the greater harm, but the exception must be declared, scoped, receipted, and revisitable.

## 10.5 Look-First at correction boundaries

Before an actor overwrites, supersedes, or repairs canonical state, it reattaches to the exact current subject. This implements Prompted LLC's Look-First custody discipline. The read is how the correcting actor takes ownership of both the state being unmade and the successor being constructed. [10]

A correction that does not inspect its predecessor may accidentally erase proofs, nonclaims, held questions, stakeholder standing, or external effects that remain live. PHS therefore treats predecessor inspection as part of lawful correction, not as optional context gathering.

# 11. Agentic systems and sovereign continuity

## 11.1 Governed verification swarms

PHS allows agents to fan out across proofs while remaining structurally unable to mutate canon or overclaim. A source checkpoint may dispatch dependency inspection, clean-clone reproduction, direct remote readback, security review, schema validation, lineage inspection, license review, policy conformance, and artifact-integrity verification concurrently.

![Figure 4. A governed proof swarm scales observers while retaining one convergence path.](figures/figure04_proof_swarm.png){width=78%}

Each agent receives a bounded contract:

```text
exact subject
+ permitted evidence surface
+ authority ceiling
+ receipt predicate
+ stop condition
+ convergence destination
```

The contract is smaller than a general mandate. The agent need not infer project-wide authority from context. It can fail safely by emitting a bounded receipt or hold.

## 11.2 Session-independent autonomy

Many autonomous systems store continuity in mutable task databases, chat summaries, working-directory residue, model memory, or branches whose authority is unclear. These surfaces may be useful, but none is sufficient as canonical evidence.

PHS provides durable epoch boundaries. One model may create source. A second may independently acquire and reproduce it. A third may inspect receipts. A human or governed authority may admit the carrier. Canon remains external to all of them.

Continuity therefore need not depend on the same model, context window, vendor, operator, machine, worktree, or repository host. This is model-independent continuation and session-independent autonomy.

## 11.3 AI-generated implementation becomes bounded state

AI assistance can accelerate generation, but generated assertions are not evidence because they are fluent or internally coherent. PHS separates:

```text
generation
admission
immutable identity
independent reproduction
evidence carriage
canonical closure
```

The system can accept AI-generated source without accepting AI-generated confidence. Plausible output becomes independently checkable state.

## 11.4 Scaling law

Let n be the number of independent proof workers and let canonical mutation remain one ordered path. Subject to resource and dependency constraints, proof throughput may increase with n without increasing canonical writer count.

More intelligence does not have to mean more authority.

The phrase "unbounded parallel reasoning" describes a topological property, not infinite physical capacity. The protocol does not require authority to scale with observer count. Real systems remain bounded by compute, network, human attention, predicate cost, dependency shape, and join latency.

## 11.5 Approval loops do not scale, but judgment remains causal

Prompted LLC's public Ubiquity framing distinguishes human judgment from permanent approval queues. At low volume, a human approval loop may provide meaningful review. At production agent throughput, the same loop tends toward one of three failures: rubber-stamping, backlog, or lost visibility. None is governance. [28]

PHS does not remove the human. It moves human judgment to load-bearing edges:

- novel or weakly precedented state;
- high consequence or poor reversibility;
- ambiguous standing or authority;
- conflicting proof classes;
- exception admission;
- correction of canonical assumptions;
- deployment, acceptance, or outcome declarations that require human or institutional standing.

The judgment then becomes reusable structure. The receipt preserves what was decided, under which subject and horizon, and what later state may inherit. The human is at the edge of earned trust rather than trapped in front of every repeated action. [8]

## 11.6 Sovereign continuity

Ubiquity defines sovereignty as agency that survives amplification. PHS contributes one evidentiary condition for that continuity: the principal must be able to determine which actors proposed, observed, admitted, deployed, accepted, or declared each transition and which claims remain unsupported. [1,4]

A system is not sovereign because it runs without interruption. It is sovereign when increased capacity does not erase authorship, judgment, correction rights, causal standing, or meaningful contribution. PHS supports that condition by refusing hidden authority amplification and by keeping canonical admission intelligible even when execution and verification are distributed.

# 12. Organizational and cross-domain enablement

## 12.1 Auditable delegation

A leader or canonical system may delegate security proof, compliance proof, reproducibility proof, distribution proof, deployment proof, or acceptance proof without delegating final admission authority. Each domain may retain its own expertise, tools, and evidentiary standard while converging through bounded receipts.

This changes delegation from:

> "I trust that team to mark the project done"

into:

> "That team owns this exact predicate over this exact subject under this exact authority ceiling."

## 12.2 Cross-organization federation

Organizations may maintain synchronized projections while preserving explicit source custody. This supports vendor-customer repository relationships, parent-subsidiary delivery, escrow, regulated handoff, sovereign or jurisdictional mirrors, acquisition transition, and open/private sibling repositories.

The architecture makes the difference between having a copy and having authority explicit. It also permits multi-party authorization behind one logical admission path when governance requires more than one signer without creating competing canons.

## 12.3 Audit without reconstructive archaeology

An auditor should not have to reconstruct a checkpoint from Slack messages, CI dashboards, terminal output, and operator recollection. A governed checkpoint history can expose:

- exact immutable subjects;
- required predicates;
- independent observations;
- named proof holders;
- authority ceilings;
- failed attempts;
- corrections;
- accepted carriers;
- unsupported claims;
- current terminal state.

Audit becomes traversal of durable evidence rather than retrospective storytelling.

## 12.4 Bounded compliance claims

Compliance evidence can be partitioned by what it actually proves.

| Horizon | Example claim |
|---|---|
| Source inspection | The selected source satisfies a declared source policy |
| Build reproduction | The declared artifact can be recreated under the stated environment |
| Distribution readback | The exact artifact is reachable from intended surfaces |
| Deployment readback | The declared runtime exposes the admitted version |
| Runtime observation | The system behaved as observed during a bounded interval |
| Stakeholder acceptance | A named stakeholder accepted a specific deliverable |
| Outcome measurement | A declared real-world result was measured under a stated method |

One receipt class cannot masquerade as another. PHS provides the topology; domain-specific standards provide predicates.

## 12.5 Beyond source repositories

Git is the reference implementation, but the primitive is more general:

> Given a strongly identified subject, partition required evidence by the earliest horizon at which each fact can lawfully be observed; execute independent proof shards concurrently; converge them into a descendant carrier; and recursively advance until the declared closure predicate is satisfied.

| Domain | Strongly identified subject | Orthogonal proof surfaces | Example carrier |
|---|---|---|---|
| Database migration | Migration package and preimage digest | Staging replay; target-schema readback | Migration receipt bundle |
| Infrastructure change | Signed plan or immutable configuration | Provider-state readback; independent policy evaluation | Change-state carrier |
| Model release | Weight and configuration digests | Registry readback; independent evaluation or reproduction | Model release manifest |
| Dataset admission | Dataset snapshot and schema digest | Integrity scan; independent sampling or policy validation | Dataset admission record |
| Policy publication | Policy document digest | Publication readback; authorized review or signature verification | Executed policy packet |
| Legal execution | Final document digest | Signature validation; custodian readback | Execution certificate |
| Media production | Master asset and edit-decision digest | Independent render; distribution endpoint readback | Release manifest |
| Clinical workflow | Versioned workflow package | Simulation; deployed-configuration readback | Governed change packet |
| Supply-chain custody | Lot or artifact identity | Custodian receipt; independent inspection | Chain-of-custody carrier |
| Autonomous mandate | Signed task or covenant identity | Independent predicates; effect readback | Mandate completion carrier |

The substrate needs six properties: strongly identified subjects, ordered successor state, independently observable proof surfaces, durable receipts, explicit authority ceilings, and governed convergence.

# 13. Security and threat model

PHS reduces several classes of false confidence, but it is not a universal security mechanism. Its guarantees are bounded by the quality of identities, predicates, environments, receipt authenticity, standing, and canonical authority.

## 13.1 Threats addressed structurally

| Threat | PHS response |
|---|---|
| Stale local remote view | Require direct target readback for distribution claims |
| Push-success overclaim | Separate operation result from observed remote state |
| Hidden authoring residue | Require independent acquisition and declared reproduction |
| Parallel writers creating divergent canon | Retain one ordered admission lane |
| Projection mistaken for authority | Encode projection as nonauthoritative custody |
| Receipt self-certifying its future | Make the carrier a successor proof subject |
| Correction erasing failure | Preserve subject-bound failure receipts and lineage |
| Agent observation becoming mutation | Enforce authority ceilings and governed join |
| Source proof laundering into outcome | Preserve separate evidence classes and nonclaims |
| Task success laundering into mission success | Require typed cross-horizon admission |
| Large synthetic evidence acquiring field authority | Preserve evidence-lane identity and standing |
| Session loss becoming governance loss | Preserve finite re-entry state outside model memory |

## 13.2 Threats requiring additional controls

**Dishonest or compromised observers.** A verifier can lie. Signatures identify a signer and protect bytes; they do not make a false statement true. High-assurance profiles may require independent observers, trusted execution, reproducible commands, cross-checking, organizational separation, or diverse implementations.

**Compromised canonical authority.** A single logical writer prevents ambiguity but may become a capture or availability point. PHS makes authority singular and inspectable; it does not guarantee benevolence. Governance may require quorum authorization, separation of duties, emergency succession, and revocation behind the one logical admission path.

**Weak predicates.** A perfectly executed test proves only what the test specifies. Predicate design remains a domain responsibility. Coverage, adversarial testing, mutation testing, formal specification, and independent review may strengthen the predicate surface.

**Untrusted time.** Wall-clock timestamps may be manipulated. Systems requiring strong temporal evidence should use signed time, transparency logs, causal ancestry, monotonic sequence numbers, or trusted hardware.

**Environment equivalence.** A detached clone can reveal local residue without proving a materially different hardware, jurisdictional, organizational, or trust environment. Independence levels must be explicit.

**Confidential evidence.** Durable receipts may expose sensitive paths, identities, configurations, or results. Implementations may require redaction, access control, encrypted evidence, selective disclosure, or zero-knowledge techniques.

**Network partitions and availability.** Serial canon may preserve consistency while reducing availability during authority loss. PHS deliberately does not solve this by admitting competing canonical histories. Recovery and succession policy must be specified separately.

**Denial through endless proof.** Proof requirements can become an instrument of non-closure. PHS therefore requires declared predicates, required-versus-optional shards, time bounds, escalation, and a lawful exception path where delay becomes the greater harm. FORKED's dual-clamp doctrine is relevant here: both premature certainty and trauma-driven non-closure are hazards. [5]

## 13.3 Trust is decomposed, not eliminated

The system does not demand blanket trust in the originating developer, AI generator, authoring machine, Git host, push command, CI service, or summary document. It decomposes trust into smaller claims and makes their boundaries inspectable.

PHS does not make trust unnecessary. It makes the location, basis, and limit of trust visible. This aligns with Prompted LLC's trust-as-behavior doctrine: trust is not a posture or a claim, but the observed behavior of the substrate over time, with movement of the trust boundary serving as evidence. [30]

# 14. Relationship to the Ubiquity corpus

PHS is most legible when placed inside the existing Prompted LLC corpus rather than treated as an isolated Git protocol.

## 14.1 Ubiquity: constitutional substrate

Ubiquity supplies the parent telos: capacity should increase without collapsing agency, authorship, judgment, or meaningful contribution. Its governance primitives include anchors, rays, absorbers, signals, warrants, rules, jurisdiction, lifecycle, correction memory, and earned autonomy. PHS is one evidence-control primitive inside that broader system. [1,2,4]

## 14.2 Fractal Quivers of Quivers: living responsibility topology

FQoQ supplies the graph language for lawful traversal, standing, authority, cost, receipts, absorbers, telos, and forbidden motion. PHS narrows that living quiver into bounded proof DAGs over exact subjects. [6]

## 14.3 Computing Around the Open Center: bounded local computation

The open-center and splat mechanics prevent a working local representation from becoming a universal crown. PHS applies the same anti-capture rule to checkpoint closure: a branch may close while the stronger center remains open. Repository proof may close without implying deployment or outcome. [7]

## 14.4 FORKED: horizon integrity and correction

FORKED contributes the direct parent doctrine of horizon noncollapse, source-tense preservation, correction graphs, parent-gated estates, observer-indexed state, and local-green/global-red detection. PHS specializes those mechanics to the temporal ordering of evidence carriers. [5]

The FORKED publication program itself preserves a related discipline: papers may be drafted in parallel, but a node freezes only after incoming dependencies have published versioned source packages and the dependent paper has rerun its citation, claim, and configuration gates. Draft parallelism does not erase evidentiary order, and no paper inherits universal applicability from its parent. [12]

## 14.5 Context Grapple Gun: reviewed judgment lifecycle

Context Grapple Gun applies a portable Ubiquity lifecycle:

```text
capture
-> human review
-> scoped promotion
-> hydration into future sessions
```

It distinguishes rendered context from constitutional source and treats a cognitive pull request as the reviewable seam before working assumptions become durable. PHS can serve as the deeper proof topology beneath such promotions when the lesson, rule, or context package must be bound to exact source and independently checked. [9,29]

## 14.6 Human judgment: edge of earned trust

Prompted LLC's human-judgment doctrine places people at the edge of earned trust rather than as permanent checkpoints. PHS supplies a way to identify those edges: shallow evidence, high consequence, ambiguous authority, conflicting receipts, irreversible state, or cross-horizon promotion. The resulting judgment becomes a receipt-bearing part of later governance rather than vanishing with the session. [8]

## 14.7 Look-First: custody at overwrite

Look-First requires reattachment to canonical state before acting on it. PHS operationalizes that requirement at source selection, correction, carrier creation, and terminal reconciliation. The actor must know which exact subject and proofs its successor will preserve, supersede, or leave open. [10]

## 14.8 Successor topology: continuity without runtime inheritance

The Prompted LLC successor-topology doctrine distinguishes continuity of identity, purpose, invariants, scars, proofs, and attribution from continuity of implementation. A successor may replace UI, provider, model, schemas, repository structure, or runtime topology without turning a sibling system into an ancestor or erasing artifact-level provenance. [11]

PHS is compatible with that transformation. Proof attaches to exact subjects and lawful successor edges, not to an assumption that implementation must remain static.

# 15. Relationship to adjacent technical work

PHS uses existing primitives and is designed to integrate with existing standards. Its contribution lies in the control law that orders them.

## 15.1 Git commits, branches, refs, worktrees, and notes

Git provides immutable content-addressed objects and a commit graph. Branches and worktrees support parallel authoring and execution. Remote refs and remote-tracking refs support distribution and local observation. Notes can attach metadata without modifying a referenced object. [16-19]

None of these mechanisms, individually, partitions checkpoint evidence by temporal attainability, requires orthogonal proof fan-out over one fixed subject, converges receipts under one admission authority, and recursively treats the carrier as a new proof subject.

PHS is not a replacement for Git. It is a protocol implemented over and beyond Git's storage and transport semantics.

## 15.2 in-toto and software supply-chain attestations

in-toto records supply-chain steps, materials, products, commands, environments, and byproducts. Its attestation model is a natural encoding surface for PHS receipts. [20]

PHS adds an explicit checkpoint topology: horizon partitioning, serial canon, zero-authority proof lanes, governed join, recursive carrier proof, deterministic re-entry, and cross-horizon noncollapse.

## 15.3 SLSA provenance

SLSA provenance describes where, when, and how an artifact was produced and provides guidance for verification and distribution. PHS can use SLSA provenance as a build or source receipt. It does not treat provenance as complete checkpoint closure unless the declared PHS horizons and authority predicates are also satisfied. [21]

## 15.4 Reproducible Builds

Reproducible Builds provides an independently verifiable path from source to bit-identical artifacts when source, environment, and instructions are controlled. PHS treats reproducibility as one possible proof shard. It additionally governs remote availability, receipt carriage, authority, correction, and recursive closure. [22]

## 15.5 Artifact attestations and transparency logs

GitHub artifact attestations establish build provenance for binaries and container images and support later verification. Sigstore Rekor records signed supply-chain metadata in a tamper-resistant transparency log. These systems can strengthen authenticity, availability, and auditability of PHS receipts. They do not by themselves define which artifact may lawfully carry which later observation or which lane controls canonical mutation. [23,24]

## 15.6 SCITT

The IETF Supply Chain Integrity, Transparency, and Trust architecture separates signed statements from later registration and receipts. It supports transparent registration services and recognizes that a receipt can prove registration without making the underlying semantic statement true. [25]

SCITT is therefore highly compatible with PHS. A PHS receipt or carrier may be registered through SCITT, and SCITT receipts may strengthen availability and inclusion evidence. PHS contributes the horizon-specific subject, authority, convergence, correction, and carrier-recursion topology around those statements.

## 15.7 RATS and conceptual message wrappers

The IETF Remote ATtestation procedureS architecture separates Attesters, Verifiers, and Relying Parties and distinguishes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. RFC 9999 adds a Conceptual Message Wrapper that can encapsulate these typed messages and aggregate them into collections without collapsing their message classes. [26,27]

PHS shares the refusal to collapse evidence generation, verification, and reliance. It differs in focus: PHS governs evolving canonical state across temporal horizons and requires descendant carriage when later observations cannot lawfully inhabit the original subject.

## 15.8 Single-writer systems and distributed consensus

PHS shares the consistency intuition of single-writer systems: one logical path serializes accepted mutation. It differs from distributed consensus systems because its primary goal is not to let several authorities agree on the next canonical state. It scales observers and custodians while deliberately refusing to multiply canonical writers.

A governance profile may use multiple signers or quorum checks behind the logical writer. The invariant is one ordered admission result, not necessarily one human or one cryptographic key.

## 15.9 Comparative boundary

| System or primitive | What it already supplies | PHS distinction |
|---|---|---|
| Git objects and refs | Exact content identity, ordered history, movable refs, distributed acquisition | Does not prescribe temporal proof horizons, authority ceilings, governed joins, or recursive carrier proof |
| in-toto | Subject-bound statements about materials, products, commands, environments, and supply-chain steps | PHS adds lawful-knowability partitioning, serial canon, horizon noncollapse, and carrier recursion |
| SLSA provenance | Standardized provenance for how an artifact was produced and distributed | PHS treats provenance as one evidence class inside a larger checkpoint and authority topology |
| Reproducible Builds | Independent recreation of specified artifacts under controlled inputs and instructions | PHS treats reproducibility as one shard and separately governs distribution, carriage, authority, correction, and closure |
| SCITT | Signed statements, transparent registration, and independently verifiable receipts | PHS specifies the evolving canonical subject, proof horizon, convergence authority, correction lineage, and recursive carrier role around those statements |
| RATS and conceptual message wrappers | Separation of Attester, Verifier, Relying Party, Evidence, Attestation Results, appraisal material, and typed message aggregation | PHS specializes these distinctions to temporal successor state and one serial canonical admission path |
| Proof-Horizon Sharding | Exact subjects, earliest-lawful-knowability partitioning, parallel bounded proof, explicit authority, governed join, descendant carriage, correction survival, and finite re-entry | Integrates the full topology as one control law while remaining compatible with the adjacent encodings and assurance systems |

The table is a functional comparison, not a claim that adjacent systems cannot be profiled to implement portions of PHS.

## 15.10 Originality boundary

A bounded review found precedents for individual ingredients, including single-writer systems, clean-clone testing, provenance, attestations, trunk-centered development, remote mirrors, transparency logs, evidence appraisal, and registration receipts.

The reviewed public material did not surface the complete combination of:

```text
governed horizon noncollapse
+ earliest-lawful-knowability partitioning
+ fixed immutable subject
+ orthogonal zero-authority proof fan-out
+ governed fan-in
+ descendant receipt carrier
+ recursive carrier checkpoint
+ one serial canonical admission path
+ correction-conserving lineage
+ deterministic re-entry from the first missing proof edge
```

That finding supports attribution of the protocol design presented here. It is not a claim that no private, unindexed, or differently named predecessor can exist, and it is not a substitute for a formal patent prior-art search.


# 16. Operational emergence and bounded empirical context

PHS was not first designed as an abstract protocol and then demonstrated in a toy system. Its mechanics emerged through repeated attempts to keep a rapidly expanding agentic production environment from lying about source, proof, authority, currentness, or completion.

## 16.1 Repository lineage of the protocol

The v1.0 repository audit documented a progressive emergence:

| Date | Repository evidence | Development |
|---|---|---|
| July 23, 2026 | `f8db7cdf` | Early explicit use of remote-ref readback as proof |
| July 30, 2026 | `589a31f9` | Explicit remote-checkpoint receipt |
| August 13, 2026 | `14213d1e` | "Proof horizon" enters the governance vocabulary |
| August 30, 2026 | `1ed4255a` and descendants | Source checkpoint and later receipt behavior become systematic |
| September 1, 2026 | `ad3b1546` | State-carrier and detached-clone reproduction semantics become explicit |
| September 1, 2026 | `b4e39afa -> 3802445a -> 833f592c` | Concrete source, correction, and remote-checkpoint receipt sequence |
| September 3, 2026 | `3786e31e` and descendants | Complete source checkpoint, dual proof, receipt carrier, carrier proof, and terminal reconciliation sequence stated canonically |

At the final v1.0 audited snapshot, root main and declared remote projections resolved to the same selected commit, with secondary refs documented as checkpoint propagation lanes rather than independent authoring lanes. [14]

The chronology matters because the underlying horizon primitive was already present upstream in Ubiquity and FORKED. PHS is the point at which one consequence of that primitive became explicit enough to extract: evidence must be sharded according to the time and independent path by which it becomes knowable.

## 16.2 August 2026 production windows

Author-supplied GitHub Insights screenshots record the following nested windows on main. [15]

| Window | Gross additions | Deletions shown by Pulse | Commits | Files changed |
|---|---:|---:|---:|---:|
| August 1 - September 1 | 12,697,294 | 89,386 | 567 | 13,909 |
| August 25 - September 1 | 8,935,647 | 95,938 | 188 | 9,850 |
| August 29 - September 1 | 6,723,886 | 11,784 | 95 | 6,711 |
| August 31 - September 1 | 3,928,484 | 6,087 | 40 | 2,819 |

The nested addition windows imply:

- approximately 3.762 million additions from August 1 through August 25;
- approximately 2.212 million from August 25 through August 29;
- approximately 2.795 million from August 29 through August 31;
- approximately 3.928 million in the final 24-hour window.

Approximately 53 percent of the monthly additions shown occurred in the final three-day window, and approximately 31 percent occurred in the final 24 hours. This is a genuine acceleration in tracked integration movement, not merely a visually suggestive chart.

![Figure 5. Nested GitHub Insights windows supplied by the author. The values are gross tracked additions, not a quality or outcome metric.](figures/figure05_operational_windows.png){width=92%}

## 16.3 The correction event

The weekly Code Frequency screenshot shows an early-August bucket with approximately 2.915 million additions and 1.894 million deletions, followed by later addition buckets around 2.163 million, approximately 2.6 million, and 6.745 million. The shape is consistent with a large shedding or correction event followed by a steep increase in gross additions. [15]

However, the monthly Pulse screenshot reports only 89,386 deletions for August 1 through September 1. Those two views do not reconcile on their face. They may reflect different calculation methods, branches, bucket boundaries, renamed or generated files, API limits, or GitHub interface semantics. This manuscript does not guess which explanation is correct.

The lawful claim is therefore bounded:

> The supplied screenshots show both a large weekly deletion bucket and rapidly accelerating addition windows. Exact commit-level reconstruction is required before asserting one unified monthly churn total or a causal account of the deletion event.

That discrepancy is itself an example of PHS source-tense discipline. A chart is an observation surface. It does not gain a stronger proposition merely because it fits the desired narrative.

## 16.4 What the operational evidence establishes

The screenshots establish that one named author account integrated a very large amount of tracked material across thousands of files and hundreds of main-branch commits during August 2026, with strong concentration in the final week and final three days. They also show zero pull requests and zero issue activity in the selected views. [15]

Those facts do not establish that every line was unique, manually authored, runtime source, correct, deployed, adopted, or valuable. The corpus includes executable source, tests, migrations, generated artifacts, documentation, receipts, audit logs, lineage, source packets, and other proof-bearing state.

The more defensible description is:

> **Forge entered a post-comprehension-scale production regime in which gross tracked integration movement exceeded the practical capacity of conventional line-by-line human review, while the system increasingly relied on exact subjects, bounded predicates, receipts, correction lineage, and serial canonical convergence.**

## 16.5 What remains an inference

The timing supports, but does not prove, an inference that reusable governance mechanics reduced marginal coordination cost as they became systematic. A plausible mechanism is:

```text
reusable invariants
-> smaller bounded contracts
-> parallel proof surfaces
-> durable receipts
-> deterministic re-entry
-> less repeated context reconstruction
-> lower marginal coordination cost
-> more admissible work per unit of founder attention
```

This manuscript does not claim that PHS alone caused the August curve. The observed acceleration could also reflect model capability, increased operator fluency, changed work mix, generated source packets, repository consolidation, automation, or other factors.

A proper empirical study should bind every measurement to exact commits and path classes, distinguish gross churn from net growth, identify exact-content duplicates and derived carriers, separate runtime/tooling/test/migration/proof/documentation lanes, and measure defect discovery, hold frequency, correction rate, re-entry latency, join latency, clean-clone success, deployment readback, and externally observed outcomes.

## 16.6 Zero pull requests as a governance signal

At this scale, the absence of pull requests would ordinarily indicate a missing control surface. PHS offers a different interpretation only when the replacement controls are real and receipted.

The pull request is not the invariant. The invariant is that candidate state cannot become accepted canonical state without exact subject identity, declared predicates, independent evidence where required, bounded authority, correction-preserving lineage, and governed convergence.

A zero-PR workflow without those controls is ungoverned. A zero-PR workflow with those controls may be governed through a different primitive. The burden is on the receipts, not the rhetoric.

# 17. Origin, attribution, and invention method

## 17.1 Canonical attribution

Breyden E. Taylor designed Proof-Horizon Sharding at Prompted LLC as part of the Ubiquity architecture's attempt to coordinate increasingly capable human-and-agent systems without collapsing authorship, judgment, correction, or canonical authority.

The governed-horizon invention is upstream. It is expressed in FORKED's explicit horizon geometry and horizon-noncollapse doctrine. PHS's native invention is the recognition that proof itself should be partitioned by the earliest horizon of lawful knowability and that this rule requires descendant evidence carriers and recursive carrier checkpoints.

The canonical attribution statement for this paper is:

> **Breyden E. Taylor designed Proof-Horizon Sharding, a temporal evidence protocol that partitions verification according to when and through what independent path each claim can lawfully become knowable. The method serializes canonical mutation through one authoritative lane, fans an immutable subject into orthogonal proof shards, converges those observations into a lineage-bearing descendant carrier, and recursively checkpoints that carrier without allowing it to attest to its own future state. The work inherits the broader governed-horizon and horizon-noncollapse primitive developed in Taylor's Ubiquity architecture and expressed through FORKED.**

## 17.2 Invention through constraint architecture

The method emerged through an apophatic design process. Taylor designed a context assembly and execution environment that repeatedly enforced a perimeter of invalid states:

- no self-attestation;
- no proof-class collapse;
- no horizon-authority laundering;
- no branch or projection authority ambiguity;
- no hidden local-state dependence;
- no unsupported maturity uplift;
- no source-to-deployment or deployment-to-outcome laundering;
- no narrative erasure of correction;
- no reliance on private session memory for continuation.

Under that perimeter, the lawful residual architecture required proof to follow epistemic dependency. The source had to exist before post-source facts could be observed. Orthogonal observations could proceed in parallel. A later object had to carry them. That object could not certify its own future. Authority had to remain serial while observation fanned out.

The architecture was therefore not selected because it made a clean diagram. It was forced by repeated refusal of invalid closure.

## 17.3 AI assistance and human authorship

AI systems assisted with context compilation, source inspection, implementation, analysis, drafting, and document production under Taylor's author-defined problem frame, constraints, terminology, architecture, and attribution boundary.

The assistance functioned as instrumentation within the invention and publication process. It is not the claimed inventive contribution. The author determined the problem, apophatic perimeter, lineage, governing relations, acceptance criteria, and final account.

This distinction is consistent with the paper's own authority model: generation is not admission, and fluent output is not evidence of authorship or correctness.

## 17.4 Prompted LLC's role

Prompted LLC is the originating organization, builder and operator of the Ubiquity substrate, publication context for the parent papers, and rights holder named across the current public registry. The site's machine-readable surfaces identify Breyden Taylor as author and founder and preserve canonical citation strings, file identities, status, and rights. [1-3,12,13]

# 18. Limitations and open work

PHS defines a protocol geometry and a concrete Git profile. Several areas remain open for standardization, formal evaluation, and independent replication.

## 18.1 Stable receipt specification

A stable PHS receipt specification should define required subject bindings, horizon identifiers, predicate digests, environment descriptors, independence levels, authority ceilings, standing, nonclaims, correction links, cross-horizon edges, and convergence rules.

Compatibility profiles should map these fields into in-toto, SLSA, DSSE, OCI attestations, SCITT, RATS, Git commits, signed notes, or governed database carriers.

## 18.2 Independence levels

The protocol needs a graded vocabulary for independence, such as:

```text
L0  same process
L1  clean directory
L2  clean worktree
L3  clean clone
L4  isolated container
L5  separate host
L6  separate account or trust domain
L7  separate organization
L8  formally diverse implementation or trust root
```

Each level detects different failure classes. No single ladder fits every domain, and a profile must state which threats it addresses.

## 18.3 Trusted time and causal ordering

Repository ancestry supplies partial causal order, but cross-system evidence may require signed timestamps, transparency logs, trusted hardware, or monotonic sequence services. A formal model should specify when ancestry is sufficient and when stronger time evidence is required.

## 18.4 Canonical authority succession

A singular logical writer requires succession policy. Future work should define emergency transfer, quorum-backed admission behind one logical writer, compromise recovery, time-bounded authority, revocation, and proof of lawful authority change without creating competing canons.

Prompted LLC's successor-topology doctrine supplies one related continuity model: preserve purpose, semantic identity, invariants, apophatic boundaries, scars, proofs, and attribution while permitting replacement of implementation bodies. PHS must still specify the evidence required to admit such a succession. [11]

## 18.5 Privacy-preserving proof

Some receipts cannot be public. Selective disclosure, encrypted evidence, redacted manifests, confidential computing, and zero-knowledge proofs may allow a system to prove predicates without exposing sensitive content.

## 18.6 Formal verification

The invariants can be represented as a state machine, temporal logic specification, or theorem-prover model. Formal verification could establish properties such as:

- no self-attestation;
- no unauthorized admission;
- no untyped horizon promotion;
- deterministic next-horizon selection;
- preservation of correction lineage;
- projection nonauthority;
- termination conditions for bounded epochs.

## 18.7 Predicate quality

PHS can faithfully carry weak proof. The protocol does not automatically know whether a predicate is sufficient. Domain-specific work is required for coverage, falsification, adversarial testing, threat modeling, and calibration.

## 18.8 Empirical evaluation

Future evaluations should compare conventional and PHS workflows on:

- proof throughput;
- join latency;
- re-entry time after interruption;
- false-closure reduction;
- hidden-dependency discovery;
- correction debt;
- audit reconstruction effort;
- human judgment load;
- canonical-writer count;
- deployment and outcome claim accuracy.

The August 2026 Forge history offers a candidate longitudinal case study but is not a controlled experiment.

## 18.9 Non-Git implementations

The broader claim should be tested over database migrations, infrastructure state, model registries, policy execution, media pipelines, legal instruments, clinical workflows, and supply-chain custody. Git is a strong first substrate because its objects make temporal and causal boundaries visible. It is not the only possible one.

## 18.10 Prior-art and standards review

The adjacent-work review in this paper is bounded. A formal prior-art search should examine not only software supply-chain systems but distributed systems, event sourcing, formal methods, safety cases, scientific provenance, chain of custody, legal execution, remote attestation, and temporal databases.

# 19. Conclusion

Proof-Horizon Sharding begins from two inherited refusals and one specialized consequence.

The first refusal, inherited from Ubiquity and FORKED, is that authority, evidence, and success do not silently collapse across horizons. The second is that possessing or rendering canonical state does not confer canonical jurisdiction. The specialized consequence is that an immutable artifact cannot truthfully claim knowledge of an event that had not occurred when it was created.

From those constraints follows a complete control law.

Canonical mutation remains serial. Proof acquisition becomes parallel. Evidence is bound to exact subjects. Distribution and reproduction remain orthogonal. Receipts converge without losing their class. A descendant carrier preserves predecessor evidence and then becomes a new proof subject. Synchronized repositories preserve canon without multiplying authority. Failures remain legible. Corrections survive. A successor resumes from the first required unproven horizon.

The result is a temporal evidence layer over content-addressed history and, more generally, a primitive for correction-surviving, proof-carrying canonical computation.

> **You can coordinate unbounded parallel reasoning around bounded serial truth.**

Many actors may propose. Many may inspect. Many may reproduce. Many may challenge. Many repositories may preserve. Many agents may continue. Yet every accepted transition retains one intelligible place in causal, evidentiary, and authority history.

That is the capability PHS enables:

> **Distributed execution, verification, and custody can scale independently while canonical state remains serial, temporally honest, reproducible, correction-bearing, and deterministically resumable.**

\newpage

# Appendix A. Protocol pseudocode

```text
function run_epoch(candidate, policy):
    h0 = disposition(candidate, policy.admission)
    if h0 != ADMITTABLE:
        return receipt(horizon=H0, result=h0)

    assert look_first(policy.current_canonical_subject)

    S = materialize_immutable_subject(candidate)
    assert exact_identity(S)
    record(horizon=H1, subject=S)

    required = policy.required_proof_shards(S)
    receipts = parallel_map(required, shard -> run_shard(S, shard))

    for R in receipts:
        assert R.subject_id == id(S)
        assert R.observed_after_subject_creation
        assert R.actor_authority <= R.authority_ceiling
        assert R.claim_class == R.horizon
        assert R.nonclaims are explicit

    if any_required_failed(receipts):
        preserve_failure_lineage(S, receipts)
        return next_unproven_or_corrective_horizon(receipts)

    J = evaluate_join(S, receipts, policy.closure)
    assert J.authority <= policy.join_authority
    if J.result != PASS:
        return preserve_join_hold(J)

    K = create_descendant_carrier(S, receipts, J)
    assert all(K.claims).observed_before(t_create(K))
    record(horizon=H3, subject=K, predecessor=S)

    carrier_receipts = run_required_carrier_proofs(K, policy)
    if any_required_failed(carrier_receipts):
        preserve_failure_lineage(K, carrier_receipts)
        return next_unproven_horizon(carrier_receipts)

    assert terminal_reconciliation(
        S, K, receipts, carrier_receipts, policy
    )
    assert cross_horizon_edges_are_admitted(policy)

    admit_canonical_successor(K)
    return CLOSED(H5)
```

# Appendix B. Reference receipt schema

```json
{
  "$schema": "https://promptedllc.com/schemas/phs-receipt-v1.1.schema.json",
  "protocol": "proof-horizon-sharding/v1.1",
  "receipt_id": "<stable-id>",
  "checkpoint_id": "<epoch-id>",
  "subject": {
    "type": "git-commit | artifact | migration | policy | other",
    "id": "<content-address-or-stable-id>",
    "tree_or_manifest_id": "<optional>",
    "predecessor_id": "<optional>",
    "correction_of": "<optional>"
  },
  "horizon": {
    "proof": "H2b.independent-reproduction",
    "parent": "repository-source",
    "stronger_horizons_open": ["deployment", "adoption", "outcome"]
  },
  "predicate": {
    "name": "<predicate-name>",
    "manifest_digest": "sha256:<digest>",
    "expected": "<expected-result>"
  },
  "method": {
    "name": "<method>",
    "version": "<version>",
    "command_or_procedure_digest": "sha256:<digest>"
  },
  "observer": {
    "actor_id": "<actor>",
    "environment_id": "<environment>",
    "independence_level": "<declared-level>",
    "standing": "<standing-basis>"
  },
  "observed_at": "<timestamp-or-causal-position>",
  "result": "pass | fail | held | indeterminate | not_applicable",
  "evidence": [
    {"type": "log | report | artifact | signature", "digest": "sha256:<digest>"}
  ],
  "authority_ceiling": "<maximum-lawful-action>",
  "nonclaims": ["<explicitly unsupported implication>"],
  "convergence_target": "<join-or-carrier>",
  "next_horizon": "<first-required-unproven-horizon>"
}
```

# Appendix C. Conformance checklist

An implementation conforms to this paper's core protocol when all answers below are yes.

1. Is every proof receipt bound to an exact immutable or strongly identified subject?
2. Is the governing horizon declared?
3. Is canonical mutation serialized through one logical authority path?
4. Can proof workers observe and receipt without automatically gaining admission authority?
5. Are source existence, remote distribution, independent reproduction, carrier existence, deployment, adoption, and outcome represented as distinct horizons?
6. Is direct target readback distinguished from local cached or tracking state?
7. Does reproduction acquire the exact subject without undeclared mutable inheritance from the authoring environment?
8. Are orthogonal proof shards allowed to run concurrently over one fixed subject?
9. Must required shards pass before their observations enter an admitted carrier?
10. Does the join preserve receipt classes rather than flatten them into one undifferentiated status?
11. Is the carrier prohibited from proving events that occur after its own creation?
12. Does the carrier become a new proof subject when its own propagation or reproduction matters?
13. Are synchronized copies explicitly denied independent canonical authority?
14. Do failed and corrected attempts remain bound to their original subjects and visible in lineage?
15. Can a successor determine the next required horizon without relying on private process memory?
16. Does terminal closure state exactly which domain is closed and which stronger domains remain unproven?
17. Does any cross-horizon promotion require a typed edge with standing, authority, evidence, and externality accounting?
18. Does an actor reattach to current canonical state before authoring an overwrite or correction?
19. Are human judgments inserted at declared earned-trust edges and carried forward as evidence?
20. Are receipt authenticity, accuracy, independence, standing, and authority represented as distinct questions?

# Appendix D. Selected glossary

**Admission.** The governed transition by which candidate material becomes accepted state without implying deployment, adoption, or outcome.

**Apophatic nonclaim.** An explicit statement of what an artifact or receipt does not prove.

**Authority ceiling.** The maximum class of mutation or claim a lane, actor, or receipt may lawfully perform.

**Canon.** The accepted source of truth for a declared scope, whose transitions are governed and evidence-bounded.

**Canonical projection.** A synchronized copy or derived expression of canonical state that does not independently decide what becomes canonical.

**Carrier.** A durable object transporting state, evidence, lineage, or receipts across a transition.

**Checkpoint epoch.** A bounded interval from candidate disposition through the proof and carrier horizons required for declared closure.

**Correction conservation.** The property that failed or superseded attempts remain intelligible and subject-bound rather than being retroactively converted into success.

**Correction debt.** The downstream burden created when state was accepted before adequate conformation or later became stale.

**Cross-horizon edge.** A typed, governed transition through which a claim may acquire standing at a stronger or different horizon.

**Detached-clone reproduction.** Re-execution of declared validations from a newly acquired exact subject without relying on the mutable authoring checkout.

**Evidence ceiling.** The strongest conclusion supported by available evidence.

**Evidence shard.** A proof bundle confined to one horizon and failure surface.

**Finite re-entry.** Deterministic resumption from the first required unproven horizon.

**Governed horizon.** A purpose, authority, evidence, consequence, and success jurisdiction that does not silently collapse into another.

**Horizon noncollapse.** The refusal to allow authority, success, or evidence at one horizon to become standing at another without an admitted cross-horizon edge.

**Independent acquisition.** Retrieval of a subject through a declared surface without inheriting undeclared mutable authoring state.

**Join receipt.** Evidence that all required fan-out lanes completed and were checked before convergence.

**Lawful knowability.** The earliest horizon at which a proposition can be directly established about an exact subject under the declared method, standing, and authority.

**Look-First.** The custody discipline requiring an actor to reattach to current canonical state before authoring an overwrite or successor transition.

**Nonclaim.** An explicit denial of an unsupported implication.

**Proof.** Evidence satisfying a declared predicate for a bounded claim; not necessarily mathematical proof.

**Proof horizon.** The highest truth boundary earned by the exact available evidence.

**Proof-Horizon Sharding.** Partitioning verification according to when and through what independent path each fact can truthfully become known.

**Proof-only lane.** A lane permitted to inspect and report but prohibited from mutating canonical source.

**Quiet point.** A terminal state in which all predicates inside the declared scope are satisfied and no hidden residue remains.

**Receipt.** A durable record binding a claim to its subject, method, observation, result, authority, and limitations.

**Receipt recursion.** The rule that a carrier may prove its predecessor but cannot contain future observations about its own later state.

**Remote-ref readback.** Direct observation of named refs on a target remote, compared against an exact selected subject.

**Serial authority.** The rule that accepted canonical transitions enter through one ordered mutation path.

**Source-bearing subject.** The immutable object carrying the selected source tranche whose later propagation and reproduction will be verified.

**Source-tense.** The explicit status of a proposition as source, observed, synthesized, inferred, declared, executed, accepted, or outcome-bearing.

**Temporal admissibility.** The requirement that an observation exist before an artifact may lawfully carry it.

**Temporal self-attestation.** The invalid implication that an immutable artifact can certify events occurring only after it exists.

**Truth horizon.** The boundary between what is established and what remains pending, held, intended, inferred, or unknown.

# Appendix E. Lineage and claim register

| Claim or mechanic | Lineage class | Source | PHS treatment |
|---|---|---|---|
| Governance substrate for sovereign adaptive systems | Inherited | Prompted LLC / Ubiquity | Constitutional parent |
| Sovereignty as agency surviving amplification | Inherited | Prompted LLC / Sovereign Continuity | Telos and continuity condition |
| Governed quiver and lawful traversal | Inherited | Fractal Quivers of Quivers | Proof and authority graph substrate |
| Open center and splat mechanics | Inherited | Computing Around the Open Center | Bounded checkpoint and scoped closure geometry |
| Governed horizon geometry | Inherited | FORKED | Parent horizon model |
| Horizon noncollapse | Inherited | FORKED | General rule specialized to evidence |
| Look-First custody | Inherited | Prompted LLC / Look-First | Subject-selection and correction discipline |
| Human judgment as reusable structure | Inherited | Prompted LLC / Ubiquity | Human authority at earned-trust edges |
| Successor continuity without implementation identity | Inherited | Prompted LLC / Successor Topology | Canonical succession and provenance boundary |
| Temporal self-attestation problem | PHS-native formulation | PHS | Core problem statement |
| Earliest lawful knowability as proof partition key | PHS-native | PHS | Core sharding rule |
| Fixed-subject orthogonal proof fan-out | PHS-native composition | PHS | Parallel verification topology |
| Zero-authority proof lanes | PHS-native composition | PHS | Observer scaling without writer scaling |
| Descendant receipt carrier | PHS-native composition | PHS | Durable carriage of later observations |
| Recursive carrier checkpoint | PHS-native composition | PHS | No-self-attestation enforcement |
| Correction conservation and finite re-entry | PHS-native derivation | PHS | Failure and continuity semantics |

# References

[1] Prompted LLC. "Prompted LLC - Ubiquity, Context Grapple Gun, Corpus." https://promptedllc.com/. Accessed September 4, 2026.

[2] Prompted LLC. "Prompted LLC - Governance Substrate for Sovereign Adaptive Systems." https://promptedllc.com/prompted-llc. Accessed September 4, 2026.

[3] Prompted LLC. "Breyden Taylor - Founder, Prompted LLC." https://promptedllc.com/founder. Accessed September 4, 2026.

[4] Prompted LLC. "Sovereign Continuity - The Root Frame for Sovereign Adaptive Systems." https://promptedllc.com/sovereign-continuity. Accessed September 4, 2026.

[5] Taylor, B. E. (2026). *FORKED - Observer-Indexed Reality, Suspension Lattices, and Mission-State Integrity* (Version 2.0 foundational whitepaper). Prompted LLC. https://promptedllc.com/forked. Raw source: https://promptedllc.com/papers/forked-v2/PAPER.md.

[6] Taylor, B. E. (2026). *Fractal Quivers of Quivers - A Mathematical Substrate for Ubiquitous Agent Governance*. Prompted LLC. https://promptedllc.com/fractal-quivers-of-quivers.

[7] Taylor, B. E. (2026). *Computing Around the Open Center: Splat Mechanics, Fractal Quivers of Quivers, and a Governance-Native Compute Paradigm* (Version 1.0 preprint). Prompted LLC. https://promptedllc.com/computing-around-the-open-center.

[8] Prompted LLC. "Human Judgment in AI Systems - Reusable Structure, Not a Bottleneck." https://promptedllc.com/human-judgment-in-ai-systems. Accessed September 4, 2026.

[9] Prompted LLC. "Context Grapple Gun - Portable Governance Lifecycle for Claude Code." https://promptedllc.com/context-grapple-gun. Accessed September 4, 2026.

[10] Prompted LLC. "Look-First - Reattach to Canonical State Before Acting." https://promptedllc.com/look-first. Accessed September 4, 2026.

[11] Prompted LLC. "Successor Topology - Ubiquity Canonical V2 Lineage Lock." https://promptedllc.com/successor-topology. Accessed September 4, 2026.

[12] Prompted LLC. *agents.txt - Machine-Readable Agent Interface Specification*, Version 4.1, updated August 21, 2026. https://promptedllc.com/agents.txt.

[13] Prompted LLC. *papers-registry.json*, Schema `prompted.papers-registry.v1`, Version 1.3, updated July 29, 2026. https://promptedllc.com/papers-registry.json.

[14] Taylor, B. E. (2026). *Proof-Horizon Sharding: Correction-Surviving, Proof-Carrying Canonical Computation* (Technical Whitepaper 1.0). Prompted LLC. Author-provided source manuscript, September 2026.

[15] Taylor, B. E. (2026). Author-supplied GitHub Insights screenshots for `forge-canonical-fed`, covering Code Frequency and Pulse windows from August 1 through September 1, 2026. Unpublished operational evidence supplied with this revision.

[16] Chacon, S., and Straub, B. "Git Internals - Git Objects." *Pro Git*, 2nd ed. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects.

[17] Chacon, S., and Straub, B. "Git Branching - Remote Branches." *Pro Git*, 2nd ed. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches.

[18] Git Project. "git-notes Documentation." https://git-scm.com/docs/git-notes.

[19] Git Project. "git-worktree Documentation." https://git-scm.com/docs/git-worktree.

[20] in-toto Project. "Link Attestation Predicate, Version 0.3." https://in-toto.io/attestation/link/v0.3.

[21] SLSA. "Build Provenance, Specification Version 1.2." https://slsa.dev/spec/v1.2/build-provenance. See also "Distributing Provenance." https://slsa.dev/spec/v1.2/distributing-provenance.

[22] Reproducible Builds Project. "Definitions: When Is a Build Reproducible?" https://reproducible-builds.org/docs/definition/.

[23] GitHub. "Using Artifact Attestations to Establish Provenance for Builds." https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations.

[24] Sigstore. "Rekor Transparency Log Overview." https://docs.sigstore.dev/logging/overview/.

[25] IETF. *RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains*. Supply Chain Integrity, Transparency, and Trust (SCITT), June 2026. https://www.rfc-editor.org/rfc/rfc9943.

[26] IETF. *RFC 9334: Remote ATtestation procedureS (RATS) Architecture*. 2023. https://www.rfc-editor.org/rfc/rfc9334.

[27] Birkholz, H., Smith, N., Fossati, T., and Tschofenig, H. *RFC 9999: Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW).* IETF, July 2026. https://www.rfc-editor.org/rfc/rfc9999.

[28] Prompted LLC. "Why AI Approval Loops Do Not Scale." https://promptedllc.com/why-approval-loops-do-not-scale. Accessed September 4, 2026.

[29] Prompted LLC. "Cognitive Pull Requests - Reviewable Seam for AI-Assisted Work." https://promptedllc.com/cognitive-pull-requests. Accessed September 4, 2026.

[30] Prompted LLC. "Trust as Behavior." https://promptedllc.com/trust-as-behavior. Accessed September 4, 2026.

# Acknowledgment

AI systems assisted with context compilation, implementation analysis, editorial synthesis, citation checking, and document production under Breyden E. Taylor's author-defined problem frame, Ubiquity lineage, apophatic perimeter, and protocol constraints.