Skip to content

GH-OS estate rollout and conformance campaign

Identifier: GHOS-ESTATE-ROLLOUT-001
Tracker: grandchallenge/MATH-PROGRAMME#724
State: GHOS_ESTATE_CONFORMANCE_GREEN
Canonical manifest: governance/ghos_estate_rollout_campaign.json
Canonical estate ledger: governance/ghos_estate_conformance_ledger.json
Documentary closure: governance/rebuild_evidence/GHOS-ESTATE-ROLLOUT-001/closure_contract.json

Purpose

GH-OS provides durable execution routing for bounded, replaceable conversational agents: workflow-byte classification, persistent-controller admission, candidate-independent enforcement, hostile rejection, and protected readback.

This campaign extended those guarantees across the active grandchallenge GitHub estate. It did not redesign GH-OS and did not create mathematical, certification, constitutional, publication, production, commercial, or external-claim authority.

Terminal result

The frozen estate contains 14 repositories by stable GitHub repository ID. The terminal reconciliation re-read the live installed grandchallenge estate and found exactly the same 14 repositories, all unarchived, with no unaccounted active, archived, or inactive repository.

All 14 repositories now have the governed terminal disposition GHOS_ROUTING_ENFORCED. The estate ledger records:

  • repository_count: 14;
  • terminal_green_count: 14;
  • shared_gate_audit_pending_count: 0;
  • applicable_routing_gap_count: 0;
  • baseline_scan_pending_count: 0;
  • blocked_count: 0;
  • estate_terminal: GHOS_ESTATE_CONFORMANCE_GREEN.

Repository-local evidence remains bound to each target repository's protected bytes, controller identity, routing registry, protection model, benign proof, hostile proof, and protected readback. The estate terminal does not replace those repository-local receipts.

Protected campaign admission

The campaign definition was admitted through protected PR #726. Historical handoff material remains useful for reconstruction but does not override the terminal ledger or the streamlined execution policy.

Current execution and closure follow MP-STREAMLINED-EXECUTION-001: evidence binds to the material routing/control object; unrelated protected-main movement does not invalidate evidence; routine bounded integration does not acquire a new Human Steward gate merely because a repository head moved.

Shared gate

The admitted shared external routing gate remains:

  • repository grandchallenge/.github;
  • commit ef1cce6029233a68cf46063cea2384772fcae613;
  • path scripts/ghos_execution_routing_gate.py;
  • blob f9f85937713046eacdc79c532046c676cbb4550c;
  • SHA-256 fc0a9a4d20de72e9fbc04c8cd54cffc3a6e4657fb09e7978b360616bd5e94a17.

Consumers pin governed gate bytes by immutable identity and digest rather than following mutable branch state. No new persistent controller was admitted by the estate rollout; repository-bound GitHub Actions remained the admitted controller where the derived topology required persistent execution.

Campaign invariant

For every active repository, durable protected state must answer:

  1. What direct execution surfaces exist?
  2. What safety-relevant features are present in their actual bytes?
  3. What execution topology is required?
  4. Which controller is admitted to provide that topology?
  5. Which candidate-independent required check enforces the routing decision?
  6. Which material evidence proves the protected repository is conformant?

No registry entry, README, issue statement, candidate-local validator, or agent assertion may downgrade a topology derived from executable workflow state.

Terminal estate by phase

Phase 0 — COMPLETE

  • grandchallenge/.github — GHOS_ROUTING_ENFORCED;
  • grandchallenge/gcl-standards — GHOS_ROUTING_ENFORCED;
  • grandchallenge/MATH-PROGRAMME — GHOS_ROUTING_ENFORCED.

The shared-gate successor was admitted and hostile-proven. Reference repositories retain their own protected routing controls.

Phase 1 — COMPLETE

  • grandchallenge/INTELLECT — GHOS_ROUTING_ENFORCED;
  • grandchallenge/MATHFORGE — GHOS_ROUTING_ENFORCED;
  • grandchallenge/MATHSOLVE — GHOS_ROUTING_ENFORCED;
  • grandchallenge/MATHCERT — GHOS_ROUTING_ENFORCED.

Each authority-chain repository reached terminal protected routing with repository-specific hostile evidence. Existing strictness semantics were preserved rather than normalized across repositories.

Phase 2 — COMPLETE

  • grandchallenge/AETHER — GHOS_ROUTING_ENFORCED.

AETHER's protected Provider profile remained strict: true. GHOS did not admit AETHER itself as GH-OS infrastructure or make GH-OS correctness dependent on AETHER availability.

Phase 3 — COMPLETE

  • grandchallenge/MODULUS — GHOS_ROUTING_ENFORCED;
  • grandchallenge/GLOSS — GHOS_ROUTING_ENFORCED;
  • grandchallenge/QUANTUM-TECHNOLOGIES — GHOS_ROUTING_ENFORCED;
  • grandchallenge/TROVE-CURATA — GHOS_ROUTING_ENFORCED.

Repository-specific protection models were preserved, including classic branch protection where applicable. Candidate-independent hostile probes failed with the expected routing-coverage rejection while protected integration remained blocked.

Phase 4 — COMPLETE

  • grandchallenge/lean-action — GHOS_ROUTING_ENFORCED;
  • grandchallenge/upload-pages-artifact — GHOS_ROUTING_ENFORCED.

Both shared-tooling repositories retain strict protected routing and immutable-tag protections. The governed downstream consumers remain pinned to immutable action identities; the rollout did not replace immutable consumer trust with branch-following references.

Per-repository proof pattern

The reusable proof pattern was:

workflow bytes -> derived features -> derived topology -> controller compatibility -> candidate-independent routing check -> protected policy -> benign proof -> hostile proof -> protected readback

For each applicable repository the campaign required exact repository/default-branch identity, complete direct-workflow inventory, byte-derived routing classification, compatible controller binding for non-bounded workflows, candidate-independent enforcement, protected required routing status, protection readback, appropriate hostile evidence, terminal protected readback, and explicit claim-boundary preservation.

Material-object-bound evidence was used throughout: unrelated protected-main movement did not invalidate a routing proof unless relevant workflow bytes, controller/security semantics, enforcement bytes, protection semantics, or merge compatibility changed.

Hostile proof semantics

Hostile candidates were safe proof objects designed to demonstrate that candidate-controlled bytes could not weaken routing coverage. The common unregistered-workflow probe intentionally left the routing registry unchanged and required the protected-base external gate to reject the candidate with deterministic workflow routing coverage mismatch while the PR remained unmerged.

This failure is evidence of control-plane enforcement; it is not a failure of the protected repository.

Persistent-controller boundary

A workflow classified PERSISTENT_CONTROLLER_REQUIRED needs a controller with durable wake, durable state, exact controller/repository identity, supported feature coverage, stale-evidence rejection, replacement recovery, interruption recovery, unauthorized-transition refusal, and separation of capability from authority.

The repository-bound GitHub Actions controller satisfied the admitted estate routing profile. GHOS routing conformance does not itself authorize a controller to exercise mathematical, certification, constitutional, publication, production, or commercial authority.

Documentary closure

The general documentary-closure route was used because this campaign is a governed cross-repository operation rather than a schema-bound Agent Council artifact.

Stage 1 admitted the closure contract through MATH-PROGRAMME PR #783:

  • exact reviewed head d05c09f7dd6de12a08b01f577c5d984d5fe53d48;
  • independent APPROVED review PRR_kwDOSuWV7M8AAAABL8tVIQ by jimsteeg;
  • Programme policy run 33702629475, success;
  • protected merge and protected-main readback 8d9549e60fde5fc81c11b84c1914e1c74a972993;
  • verified merge signature, reason valid;
  • durable protected-admission receipt on #724 comment 5518908313.

The terminal candidate reconciles the contract to CANONICAL_ON_PROTECTED_MAIN, reconciles the machine campaign manifest and this human-readable record to the 14/14 result, and proposes the estate ledger's declared terminal token. That terminal proposal becomes canonical only after independent exact-revision review, protected merge, and protected-main readback of the terminal candidate itself.

Terminal estate acceptance

GHOS_ESTATE_CONFORMANCE_GREEN requires and the terminal candidate records:

  • canonical estate inventory reconciled with the live organization estate;
  • one terminal disposition for every active repository;
  • zero unexplained workflow, topology, controller, or protection gaps;
  • shared-gate compatibility and immutable consumer pinning;
  • required hostile evidence;
  • a registered MATH-PROGRAMME documentary closure contract with protected admission/readback;
  • independent exact-revision review of the terminal candidate;
  • protected terminal readback.

The last two items are integration gates on the terminal candidate, not assertions that can be self-certified inside candidate bytes.

Claim boundary

This campaign proves workflow/control-plane conformance only. It does not prove mathematics, certify a theorem, admit a mathematical campaign, verify source correctness, issue a certificate, authorize publication, create production authority, or create novelty, priority, patentability, mechanical, manufacturing, physical, scientific, or commercial claims.