EPIC: T27 Verified Compute Layer — Proof of Concept #6655

Goal

Make T27 Verified Compute Layer a Queen-runnable EPIC and connect the existing T27, Trinity, TriOS and FPGA mechanisms into one verified engineering loop.

Core hypothesis:

Do not recompute what can be proven unchanged. Do not reconfigure what can be proven valid and preserved.

The target platform loop is:

spec/PR -> resolve change -> affected dependency graph -> build/test -> evidence -> seal -> review gate

and on failure:

failure -> canonical fingerprint -> deduplication -> prioritized GitHub issue -> Bee task -> Queen routing -> fix PR -> same verification pipeline

Review should consume verified evidence, not reconstruct it manually.

This EPIC MUST reuse existing repository mechanisms before introducing new services or duplicate protocols.

Where we are

The repositories already contain substantial pieces of this system:

• T27 contains native specifications, Seal/verify tooling, policy, Queen/runtime surfaces, test framework and graph-related specifications.
• Trinity contains Queen/review lifecycle material and the FPGA forge/adapter contract.
• TriOS contains task queues, claims, event journals and Queen execution evidence.
• trinity-fpga contains artifact-based verification/journal material and FPGA synthesis/reconfiguration evidence.
• T27 issue EPIC: T27 Verified Compute Layer — Proof of Concept #6655 already exists as the canonical Verified Compute EPIC.

The missing work is therefore not to invent another large platform. It is to establish and verify the thin cross-repository contracts that connect the existing pieces.

No claim that a complete cross-repository Change/Run/Evidence/Failure/Issue protocol already exists is accepted until the implementation is located and tested.

Queen contract

Every issue created under this EPIC MUST follow the repository's Queen-runnable standard.

Required sections, in this order:

1. ## Goal
2. ## Where we are when current state matters
3. ## Sub-tasks for an EPIC
4. ## Rules for every agent on this epic for an EPIC
5. ## Boundary
6. ## User Scenarios & Testing
7. ## Requirements
8. ## Success Criteria

A task that lacks the required executable sections is NOT a Queen-runnable task.

Hard issue-authoring rules

• No free-form issue may be created as a child task.
• Every child issue MUST name an explicit Boundary of files/specs it may change.
• Every child issue MUST contain machine-checkable Success Criteria.
• Every requirement MUST be testable or observable.
• Every task MUST state what is out of bounds when scope could be ambiguous.
• Prefer t27-native .t27 specifications when the repository's own_language.t27 policy requires them.
• Do not instruct a bee to hand-write Python/Rust/TypeScript/JavaScript/etc. when the work belongs in the t27-only surface.
• Do not hand-edit generated files.
• No invented benchmark numbers, hardware results, or novelty claims.
• Every numerical claim in a report MUST identify the command/run/commit that produced it.
• One defect/atomic change per child PR.
• No bee merges, approves, or auto-merges its own PR.
• Secrets, tokens and Railway variables MUST NOT be put in issues, specs or PRs.
• English/ASCII-only repository issue/spec content where required by the existing Queen policy.
• A child issue is not complete merely because code exists: its Success Criteria must pass.

Sub-tasks

Golden Chain Architecture — product-level module model

Golden Chain is the product architecture for the verified, executable chain from specification to physical execution and evidence. T27, TriOS and TriNet are not parallel products or a second verification stack; they provide the language, ring/module architecture, execution/network substrate and existing contracts used by Golden Chain.

Architectural hierarchy

GOLDEN CHAIN
  |
  +-- GOLD: complete product/capability
  |     |
  |     +-- Verified Compute
  |     +-- Incremental FPGA Update
  |     +-- Verified Execution / Settlement
  |
  +-- SILVER: reusable subsystem/module
  |     |
  |     +-- Change
  |     +-- Dependency Graph
  |     +-- Artifact
  |     +-- Build
  |     +-- Seal
  |     +-- Verify
  |     +-- Evidence
  |     +-- Device / Receipt
  |
  +-- BRONZE: concrete implementation
        |
        +-- .t27 specification
        +-- compiler/build implementation
        +-- FPGA forge/adapter
        +-- tests
        +-- provider/device adapter
        +-- evidence/receipt implementation

The ring level is architectural, not cosmetic. A file is an implementation artifact; a module is a reusable contract with defined inputs, outputs, dependencies, verification boundary and ownership.

Golden Chain vertical contract

The first executable vertical slice is:

SPEC -> MODULE -> BUILD -> ARTIFACT -> SEAL -> VERIFY -> DEVICE -> EVIDENCE

The broader autonomous/economic chain is:

CLIENT -> QUEEN -> BEE -> PROVIDER -> VERIFIED EXECUTION -> RECEIPT -> SETTLEMENT -> $TRI

The first PoC MUST establish the first chain without requiring the second chain to be complete.

Module contract

Every reusable module should expose, directly or through its canonical spec:

• stable module identity and ring level;
• purpose/capability;
• inputs and outputs;
• dependency closure;
• artifact identity;
• verification method and evidence;
• allowed consumers/dependents;
• failure semantics;
• version/compatibility boundary.

Ring dependency law

The intended dependency direction is:

GOLD -> SILVER -> BRONZE

Gold composes Silver capabilities. Silver depends on contracts/implementations permitted by its ring rules. Bronze contains concrete implementations and is exposed through the appropriate Gold facade/output. Existing TriOS Doctor ring rules are the reference model; do not create a second ring architecture in T27.

Existing-system reuse rule

Before creating a new spec/module, search T27, Trinity, TriOS and Trinity-FPGA for an existing contract. Extend or compose the existing mechanism when possible. New infrastructure requires an explicit reason that an existing source of truth cannot satisfy the contract.

First Golden Chain PoC

The PoC is not a standalone FPGA demo. It is the first executable Golden Chain module proving:

1. one baseline module/artifact can be built and sealed;
2. one localized change produces a new affected frontier;
3. unchanged state is explicitly identified as reused/preserved;
4. the new artifact independently verifies;
5. execution produces stable Run/Evidence identity;
6. hardware is reported only when real device evidence exists; otherwise hardware state is UNPROVEN;
7. the same evidence contract can later feed failure fingerprinting, Queen/Bee repair and provider settlement.

Non-goals for the first PoC

No new token, ledger, cryptographic primitive, marketplace, fleet scheduler or parallel FPGA lifecycle. Do not duplicate TriOS ring architecture, T27 Seal/verify, Trinity FPGA adapter/forge or existing TriNet/provider contracts.

Evolution rule

Every future Golden Chain capability should enter the tree as a module at an explicit ring level rather than as an orphan spec/file. When a Bronze implementation becomes reusable, promote its contract into Silver. When a set of Silver modules forms a complete externally consumable capability, compose them behind a Gold facade.

Phase 0 — TODAY MVP: one verified incremental update

The first objective is NOT to complete the whole platform. It is to prove one vertical slice today and use it as the executable seed for the later phases.

Target PoC:

one change -> affected graph -> incremental artifact -> seal -> verify -> execution evidence -> PASS/FAIL

For the first hardware-facing slice, use one existing supported FPGA target and one small reconfigurable block with two compatible implementations. The PoC MUST prove the identity and verification boundary; it MUST NOT claim a real partial-device update if the available target/adapter cannot demonstrate that fact.

Today sequence

1. Locate the smallest existing FPGA/forge/adapter example that can be built and verified with current repository tooling.
2. Define one tiny reconfigurable block and two compatible versions of that block.
3. Build version A and record artifact identity, dependency closure, toolchain/configuration identity and Seal.
4. Change only the block; rebuild and prove the unchanged closure is reused while only the affected artifact/region is regenerated.
5. Verify the new artifact independently and emit one machine-readable Run/Evidence record.
6. If a supported physical target is available, load the verified partial artifact and record device/transcript evidence. If not, stop at the adapter/forge boundary and mark hardware execution unproven.
7. Feed PASS/FAIL into the same review/failure contract that will later drive Issue -> Queen -> Bee.

MVP acceptance

• One reproducible command sequence creates the initial artifact and its Seal.
• One minimal change produces a second artifact with a demonstrable invalidation frontier.
• The unchanged portion is explicitly identified as reused/preserved; no full rebuild may be silently presented as incremental reuse.
• Both artifacts independently verify.
• Every execution has a stable Run identity and Evidence reference.
• A failed verification produces one deterministic failure fingerprint.
• The PoC produces a concise machine-readable verdict: PASS or FAIL, with artifact/run/evidence references.
• No new cryptographic primitive, ledger, token or parallel FPGA lifecycle is introduced.
• A hardware result is marked demonstrated only when device evidence exists; otherwise the hardware step is explicitly UNPROVEN.

Out of scope for today's MVP

• mainnet/token launch;
• general marketplace;
• multi-provider scheduling;
• full automatic repair swarm;
• broad FPGA fleet support;
• performance optimization beyond what is needed to prove incremental reuse.

Phase A — establish the verified-state model

• Inventory the existing T27 Seal, graph, policy and verification contracts before adding new ones.
• Define the canonical verified-compute vocabulary: artifact identity, dependency identity, toolchain identity, configuration identity, verification state and seal.
• Define deterministic dependency closure and invalidation semantics.
• Define/verify T27 Seal schema and canonical serialization.
• Implement/express seal, verify, invalidate, and reuse semantics in the repository's allowed t27 surface.
• Add executable tests for unchanged state, leaf change, shared-dependency change, and toolchain/configuration change.

Phase B — prove incremental reuse

• Build the minimal deterministic computation graph.
• Measure clean build, no-change rebuild, leaf-change rebuild and shared-dependency rebuild.
• Produce a reproducible invalidation-frontier report.
• Verify that unchanged artifacts are reused and affected artifacts are rebuilt.
• Record evidence identifying exactly what was reused versus rebuilt.

Phase C — trust/provenance boundary

• Document the boundary between T27 Seals and existing provenance/signing systems.
• Do not implement a new cryptographic primitive.
• Demonstrate independent verification of a seal from its recorded inputs/evidence.

Phase D — cross-repository glue contract

The glue layer MUST be a thin protocol over existing mechanisms, not a replacement for T27, TriOS or Queen.

• Inventory existing event journal, claims, queue, policy, graph, seal, evidence and Queen routing mechanisms across T27, Trinity, TriOS and trinity-fpga.
• Define one canonical change identity that can point from PR/spec/change to its affected graph.
• Define the execution/run identity linking a change to build/test execution.
• Define an evidence record linking execution to outputs, tests, logs and verification/seal state.
• Define normalized failure records containing stage, affected scope, error class and evidence references.
• Define a deterministic failure fingerprint for deduplication.
• Define failure-to-GitHub-Issue transition semantics: create a new issue when the fingerprint is new; update the existing issue when the fingerprint already exists.
• Define priority/escalation semantics so repeated failures become actionable rather than producing duplicate issue floods.
• Define the Bee task contract produced from a failure issue and the Queen routing contract that assigns it.
• Define the fix-PR linkage back to the originating failure/change.
• Define the final verification transition that closes the loop only after evidence passes.
• Keep the canonical source of truth in the appropriate existing repository; do not duplicate state merely to make the integration easier.

Phase E — automated review gate

• Resolve affected graph from a PR/spec change.
• Execute only the required build/test surface according to dependency closure and policy.
• Produce a machine-readable evidence summary.
• Verify the Seal and policy result.
• Expose a concise review state such as: affected -> executed -> passed -> sealed -> policy-pass.
• Block merge when required evidence, verification or policy state is missing or invalid.
• Permit human review to consume evidence rather than reconstructing the execution manually.
• Do not auto-merge a Bee's own PR.

Phase F — automatic failure loop

• Detect failed agent/CI execution as a first-class engineering event.
• Normalize the failure and calculate its canonical fingerprint.
• Deduplicate against existing open failure issues.
• If the failure is new, create a Queen-runnable issue with Boundary and machine-checkable Success Criteria.
• If the failure already exists, append/update evidence and occurrence metadata instead of creating another issue.
• Assign priority from deterministic policy, not arbitrary agent judgment.
• Route the issue to Queen/Bee according to existing queue/claim mechanisms.
• Require the resulting fix PR to reference the failure issue and original change.
• Re-run the same verification pipeline after the fix.
• Close the failure only when the original failure fingerprint is resolved and replacement evidence is valid.

Phase G — FPGA extension

• Specify mapping from software artifact identity to FPGA region/bitstream identity.
• Specify compatibility constraints for a reconfigurable region.
• Specify verified partial-update policy.
• Reuse the existing Trinity FPGA adapter/forge contracts rather than inventing another bitstream lifecycle.
• Only after the software invariant and cross-repository verification loop are proven, create the hardware PoC.

Phase H — hardware PoC

• Select one existing supported FPGA target. (QMTech Wukong V1, XC7A200T-FGG676, full IDCODE 0x03636093 read from the silicon, bench run 2026-10-06)
• Demonstrate two compatible implementations of a reconfigurable region. (PoC slots a/b — hand-written JTAG wrappers under the owner's owner-approved-foreign approval, PR feat(fpga): PoC slots a/b on silicon -- one JTAG boundary, two implementations (Closes #6829) #6832; five spec designs through t27c silicon the same day, all PASS)
• Seal and verify the partial artifacts before update. (t27c seal --verify reports all hashes MATCH; the die ran the sealed images)
• Demonstrate that unchanged/static logic remains operational. (static region + wrong-part control runs bracketing every bench run: Done=0/1 as expected)
• Record reproducible hardware evidence; otherwise explicitly mark the item unproven. (five specs HW_VERIFIED, 3-seed verdict AGREED, recorded in the 2026-10-06 bench comment below; the gap that remains — a transcript in a comment, not a receipt artifact in the tree — is Round-2 requirement R2-1 below)

Rules for every agent on this epic

1. Read this EPIC and the repository's current Queen policy before starting.
2. Inspect existing T27, Trinity, TriOS and FPGA mechanisms before creating a new contract.
3. Convert any child work into the exact Queen-runnable structure above.
4. Keep each child issue atomic and bee-sized.
5. Boundary is mandatory and is the authority for allowed changes.
6. Success Criteria MUST be executable checks or objectively inspectable results.
7. A failing criterion means the task is not done.
8. Preserve existing t27-only/own-language policy; do not bypass it with another language.
9. Do not modify generated output by hand.
10. Do not claim performance, novelty, FPGA support or cryptographic guarantees that were not demonstrated.
11. Every PR must reference its child issue and this EPIC.
12. No self-merge/self-approval/auto-merge by bees.
13. Keep secrets out of repository artifacts and issue text.
14. When a task cannot be expressed in the current t27 surface because of a compiler limitation, report the exact blocker rather than silently changing scope.
15. Historical prose may remain for context, but the Queen-runnable restatement is the executable contract.
16. Before creating any new issue, validate that it contains all mandatory sections and machine-checkable acceptance criteria.
17. Never create a duplicate failure issue when the canonical failure fingerprint already has an active issue.
18. Do not create a new cross-repository service when an existing journal, queue, claim, graph, seal or Queen mechanism can provide the required state.
19. Every automated transition MUST retain enough evidence to reproduce or independently verify the decision.

Boundary

This EPIC governs the proof-of-concept work for the Verified Compute Layer, its direct specifications/tests, and the minimal cross-repository integration needed to close the engineering loop.

Initial expected surfaces:

• T27 specs/** for t27-native contracts/specifications
• T27 .trinity/seals/** for generated seal artifacts when produced by repository tooling
• Trinity/TriOS existing event, queue, claim, Queen and integration surfaces identified during Phase D
• FPGA adapter/forge surfaces identified during Phase G
• docs/** only when a documentation artifact is explicitly part of a child issue
• existing compiler/test surfaces only through separately scoped child issues

Out of bounds unless a child issue explicitly adds them to its Boundary:

• unrelated compiler fixes
• unrelated provider/Queen UI work
• arbitrary generated files
• secrets/configuration
• production FPGA deployment
• replacing T27, Trinity or TriOS with a new parallel platform
• implementing a new cryptographic primitive

User Scenarios & Testing

• Given an unchanged source/dependency/toolchain/configuration state, when the verifier evaluates an existing sealed artifact, then it returns a valid/reusable result.
• Given one leaf dependency changes, when invalidation is evaluated, then only the affected dependency closure is invalidated.
• Given a shared dependency changes, when invalidation is evaluated, then every dependent artifact is invalidated and unrelated branches remain reusable.
• Given the compiler/backend identity or relevant configuration changes, when verification is evaluated, then the previous artifact is not accepted as reusable.
• Given a seal with altered evidence or artifact identity, when verification is evaluated, then verification fails.
• Given a PR changes a leaf dependency, when the pipeline resolves the graph, then only the affected verification surface is executed.
• Given a build/test fails, when the failure is normalized, then a deterministic fingerprint is produced.
• Given the same fingerprint already has an open failure issue, when the failure repeats, then no duplicate issue is created and the existing issue receives updated evidence.
• Given a new fingerprint, when automatic issue creation runs, then exactly one Queen-runnable issue is created with Boundary and machine-checkable Success Criteria.
• Given a failure issue is assigned to a Bee through Queen, when the Bee creates a fix PR, then the PR links back to the failure issue and re-enters the same verification pipeline.
• Given a fix passes with valid evidence and Seal, when the review gate evaluates it, then the failure state is resolved rather than merely marked complete by the agent.
• Given a verified FPGA static region and a compatible sealed partial artifact, when the hardware phase is eventually executed, then the update policy permits only the verified compatible region to change and preserves static logic. This remains unproven until hardware evidence exists.

Requirements

• FR-001: The EPIC and every child issue MUST use the Queen-runnable section structure defined above.
• FR-002: Every child issue MUST have exactly one explicit Boundary describing the permitted change surface.
• FR-003: Every child issue MUST contain User Scenarios & Testing, Requirements and machine-checkable Success Criteria.
• FR-004: The verified-state model MUST distinguish at least artifact identity, dependency closure, toolchain/backend identity and relevant configuration.
• FR-005: Verification MUST fail closed when required identity/evidence does not match.
• FR-006: Invalidation MUST be deterministic for the same graph state.
• FR-007: The PoC MUST distinguish reuse from recomputation and record which artifacts were reused/rebuilt.
• FR-008: Benchmark results MUST be reproducible and MUST NOT contain invented numbers.
• FR-009: FPGA claims MUST remain explicitly unproven until reproducible hardware evidence exists.
• FR-010: No new cryptographic primitive is part of this PoC.
• FR-011: The repository's existing t27-only/own-language policy takes precedence over generic implementation suggestions.
• FR-012: Every pipeline execution MUST have a stable run identity and evidence reference.
• FR-013: Every failure MUST have a deterministic fingerprint derived from normalized failure inputs.
• FR-014: Repeated identical failures MUST update an existing active issue instead of creating duplicate issues.
• FR-015: A new failure issue MUST be Queen-runnable and machine-checkable.
• FR-016: A fix PR MUST be traceable to the failure issue and originating change.
• FR-017: The final merge/review decision MUST be based on recorded evidence, verification and policy state.
• FR-018: Cross-repository glue MUST reuse existing mechanisms and MUST NOT introduce duplicate sources of truth without an explicit child-issue justification.

Success Criteria

• grep -c '^## Goal$' on this EPIC body returns 1.
• grep -c '^## Sub-tasks$' on this EPIC body returns 1.
• grep -c '^## Rules for every agent on this epic$' on this EPIC body returns 1.
• grep -c '^## Boundary$' on this EPIC body returns 1.
• grep -c '^## User Scenarios & Testing$' on this EPIC body returns 1.
• grep -c '^## Requirements$' on this EPIC body returns 1.
• grep -c '^## Success Criteria$' on this EPIC body returns 1.
• The EPIC explicitly states that child issues without the mandatory Queen-runnable sections are not accepted.
• The EPIC explicitly states that machine-checkable Success Criteria are mandatory.
• The EPIC explicitly states that Boundary is mandatory.
• The EPIC explicitly preserves the repository's t27-only policy.
• The EPIC explicitly requires reuse of existing T27, Trinity, TriOS and FPGA mechanisms before new infrastructure.
• The EPIC explicitly defines the failure fingerprint and duplicate-issue prevention requirement.
• The EPIC explicitly defines the closed loop from failure -> issue -> Bee -> Queen -> fix PR -> verification.
• No FPGA result is described as demonstrated until a child task records reproducible hardware evidence.

Definition of Done

The EPIC is complete only when the Queen can decompose the work into compliant child issues, execute their checks, and establish a reproducible chain:

source/spec -> dependency closure -> deterministic invalidation -> sealed artifact -> independent verification -> safe reuse,

and:

change/PR -> affected graph -> execution -> evidence -> verification gate,

and on failure:

failure -> fingerprint -> deduplicated issue -> Bee -> Queen -> fix PR -> same verification pipeline -> verified resolution,

followed by an experimentally verified hardware mapping if and only if the software and integration proofs succeed.

Phase I — network economy and provider settlement

The verified engineering loop is also an economic loop. Existing Trinity/TriNet work already contains compute receipts, settlement, anti-replay/no-double-pay guards, executor reputation, pool splitting, bonding/slashing and $TRI reward semantics. This phase MUST connect those existing mechanisms rather than invent a second token/payment system.

Target economic loop:

client task -> Queen -> Bee/agent -> provider GPU/compute -> execution -> evidence/verified receipt -> settlement -> $TRI reward distribution

Required participants MUST be modeled separately where applicable:

• Client/requester pays for verified work/service.
• Bee/agent executor receives reward for successfully completed, verified work.
• Compute/GPU provider/operator receives the provider share for supplying the compute capacity on which the agent execution ran.
• Spec/research/work contributor may receive a contribution share when existing economy rules assign one.
• Queen/network coordinates work and must not be treated as an unverified source of work completion.

Economic settlement MUST happen only after the same verification/evidence gates used by the engineering pipeline. A failed, stale, replayed, non-finite, or unverified execution MUST NOT receive a normal completion payout.

Existing mechanisms to reuse

The implementation inventory must explicitly locate and compose the existing Trinity/TriNet mechanisms for:

• compute-attesting receipts;
• verified compute settlement into $TRI;
• freshness / anti-replay and settled-once guards;
• compute bond escrow and challenge/slash lifecycle;
• executor reputation;
• reward-pool splitting and reputation weighting;
• existing $TRI tokenomics / staking / provider/operator economics;
• Queen/Bee task assignment and execution evidence;
• provider/GPU capacity and identity where already implemented.

Economic acceptance criteria

• A completed task has a traceable chain from requester/change to executor, compute provider, evidence/receipt and settlement.
• The settlement references the verification result; payment cannot be inferred merely from an attempted execution.
• Replayed or stale receipts pay zero.
• Incorrect challenged work can be slashed according to the existing dispute mechanism.
• Provider rewards and Bee/executor rewards are distinguishable in the settlement record.
• Reward distribution cannot exceed the configured pool.
• Repeated pipeline failures create/update one canonical engineering issue and do not create economic rewards for failed work.
• No second token, duplicate ledger, or parallel settlement protocol is introduced.
• The public product/site description and repository contracts describe the same economic loop and do not claim capabilities that are not implemented.
• Any unresolved gap between the public site and repository implementation becomes an explicit Queen-runnable child issue rather than being silently papered over.

Updated product loop

The system should be presented consistently as one platform:

client -> task/spec -> Queen -> Bee -> compute provider -> verified execution -> evidence -> settlement -> $TRI -> provider/executor/contributor rewards

The engineering side and economic side are one state machine: no verified result, no normal reward.

Additional Definition of Done

The economic layer is complete only when one end-to-end test demonstrates a real task flowing through assignment, provider-backed execution, verification/evidence, settlement and reward accounting, with the resulting state independently inspectable and with failure/replay paths proven to pay zero or follow the existing challenge/slash rules.

Queen Priority — Focus 50% of Bee Capacity on EPIC #6655

Objective

Queen MUST treat EPIC #6655 as a top-priority execution objective and direct 50% of available Bee execution capacity to this EPIC until the Epic's current acceptance criteria are satisfied or an explicit human override changes the allocation.

Allocation rule

• Target allocation: 50% of active Bee capacity to EPIC: T27 Verified Compute Layer — Proof of Concept #6655.
• Remaining 50% stays available for other work, safety/health tasks, and urgent blockers.
• Allocation is measured over the active scheduling window, not as a promise that exactly half of all historical jobs were on the Epic.
• Queen remains the coordinator; Bees execute bounded, machine-checkable child tasks.
• No Bee may self-merge, self-approve, or bypass the existing review/evidence gates.

Routing policy

1. Queen selects EPIC: T27 Verified Compute Layer — Proof of Concept #6655 before lower-priority discretionary work.
2. Queen decomposes only into the existing Epic phases/child issues and concrete module contracts; do not create duplicate architecture.
3. Prefer tasks that advance the first Golden Chain vertical slice: SPEC -> MODULE -> BUILD -> ARTIFACT -> SEAL -> VERIFY -> DEVICE -> EVIDENCE.
4. Every Bee task MUST return machine-checkable evidence, changed artifacts/specs, tests, and PASS/FAIL state.
5. Failures return through the existing fingerprint -> deduplicated issue -> Bee -> Queen -> fix PR -> verification loop.
6. When one child is blocked, Queen may redirect that Bee to the next unblocked EPIC: T27 Verified Compute Layer — Proof of Concept #6655 task while preserving the 50% capacity target.

Stop / release conditions

The 50% priority remains active until the current Phase 0/vertical-slice acceptance criteria and the applicable Epic criteria are verified, or a human explicitly changes the priority. A single green PR is not sufficient: the Golden Chain vertical evidence must be complete.

Operational invariant

One Epic, one Queen priority, many bounded Bees, one verification pipeline.

This is a scheduling directive for Queen. It does not create a second queue, second source of truth, or parallel verification system.

Progress Notifications to User

Queen MUST provide the user with direct progress notifications for this EPIC through the existing personal bot/DM notification mechanism when that mechanism is available.

Notification contract

• Track progress for EPIC EPIC: T27 Verified Compute Layer — Proof of Concept #6655 as a single canonical percentage, derived from the machine-checkable child-task/acceptance state; do not invent subjective percentages.
• Send a notification when the EPIC percentage materially changes, when a major phase/child task changes state, and when execution becomes blocked or unblocked.
• Each progress notification MUST include: EPIC EPIC: T27 Verified Compute Layer — Proof of Concept #6655, current percentage, current phase/task, PASS/FAIL/BLOCKED state, and the next concrete action.
• For hardware work, explicitly distinguish VERIFIED, UNPROVEN, and BLOCKED; never report hardware completion without device evidence.
• Notifications MUST link back to the canonical GitHub issue/PR/evidence when a link exists.
• The bot MUST notify the user directly rather than requiring the user to poll GitHub.
• The notification mechanism MUST reuse the existing Queen/bot/DM infrastructure; do not create a second notification service or parallel progress source of truth.

Example notification

Golden Chain #6655 — 37% | Phase 0 | incremental artifact verified | PASS | Next: independent verification + evidence.

Completion notification

When the Phase 0 Golden Chain vertical slice reaches its acceptance criteria, send a final notification stating 100% for that defined slice, with the verification/evidence reference. Do not use 100% for the whole EPIC unless all EPIC Definition-of-Done criteria are actually satisfied.

Acceptance

• A machine-readable progress state exists for EPIC: T27 Verified Compute Layer — Proof of Concept #6655.
• Queen can derive the percentage from actual task/verification state.
• The user receives direct bot/DM notifications on material progress and blockers.
• The notification payload contains percentage, state, current work and next action.
• No duplicate progress ledger or notification architecture is introduced.

P0 Scheduler Control — #6657

The scheduler is now a direct P0 execution dependency of this EPIC. Use the existing scheduler/lease mechanisms from #4828 and #3594; do not create a parallel scheduler.

Task: #6657 — P0: Queen Scheduler Control Layer — dispatch, leases, manual Bee control
#6657

#6657 must establish the canonical control path for automatic dispatch, manual Bee assignment, interrupt/cancellation, task-scoped Bee control, worker/provider registration, priority enforcement, stale-lease recovery, and runtime scheduler observability. The reuse/no-duplicate rule in #6657 applies to every Bee working on this EPIC.

Execution order: fix scheduler control/capacity first, then run the Golden Chain GPU PoC through that scheduler, then extend the same chain to FPGA.

Round-2 requirements (added by the owner's decision, 2026-10-06)

The owner cleared the three blockers this epic was parked on (translated from Russian: "do all three yourself"): the hand-written Verilog JTAG wrappers for the PoC slots, adding requirements to this epic directly, and the #6657 supervisor wiring in BrowserOS. What that unblocked becomes requirements:

• R2-1 — Receipt persistence by the tool. t27c silicon must write a receipt artifact into the tree (device record, full IDCODE, verdict word, seal hash, seeds, tool identity), so an HW_VERIFIED step is durable in the repository instead of durable in an issue comment. Named at the Phase H bench run as the one soft spot; now a requirement, not an observation. Landed: PR silicon: every hardware run writes a receipt artifact (R2-1/R2-2) (Closes #7041) #7044 (merged 2026-10-06) -- t27c silicon writes the receipt into .trinity/receipts/, judged by the R2-4 reader.

• R2-2 — Toolchain identity in the receipt. The receipt names the exact producer (the t27c/seal identity) that generated and verified it, tying HW_VERIFIED to the toolchain identity the Phase A vocabulary already defines. A receipt that cannot name its producer cannot be independently re-verified. Landed: PR seal: built_by -- every new seal names its build (the #7072 prerequisite) #7076 -- seal --save writes built_by; the receipt's toolchain matched it verbatim on the R2-5 bench run.

• R2-3 — Supervisor wiring, slice 1. Landed: feat(queen): task leases and the event log from specs/queen/control.t27 (#6657) BrowserOS#537 merged 2026-10-07 09:07:32Z (the bullet's earlier status is kept below for the record). feat(queen): task leases and the event log from specs/queen/control.t27 (#6657) BrowserOS#537: the Queen's dispatch loop now runs on fenced per-task leases and an append-only event log, both read from the vendored specs/queen/control.t27 by the compiler wasm at run time — no re-typed constants. Closes the wiring half of P0: Queen Scheduler Control Layer — dispatch, leases, manual Bee control #6657; fence enforcement on dispatch writes, event reactions, and the cancel/assign routes are the named next slices. Status 2026-10-07: BrowserOS#537 (feat/queen-task-lease) is green and carries owner-approved-foreign, but NOT merged -- an earlier edit of this bullet said "landed" and that was wrong (recorded here, not silently overwritten); a BrowserOS merge deploys to production, so it is the owner's.

• R2-4 — One run record per verified run. Every verified run produces one machine-readable record chaining change identity -> run -> evidence -> verdict, in the Phase D vocabulary, consumable by specs/verified/verdict.t27 (record_status). Review consumes the record; it does not reconstruct the run. Landed: contract specs/verified/run_record.t27 (PR verified: run_record -- when a set of receipts is one verified run (R2-4 spec half) #7061) + the t27c run-record reader (PR feat(verified): t27c run-record reads the receipts and judges one run (R2-4 tool half) #7130, squash 339c0443f0, closes R2-4 (tool half): t27c reads the receipts and judges one run -- plus a producer-vocabulary gap to decide #7072).

• R2-5 — The chain proven end to end on the bench (capstone). Three seeded placements of specs/fpga/ternary_link.t27 (pnr seeds 1/7/42) on the XC7A200T wrote three receipts (full IDCODE 0x3636093 read live, verdict 0xa5a532bf every time); t27c run-record judged the run complete and citable (exit 0); the citation spec specs/verified/ternary_link_run.t27 pins that judgment and is sealed. Issue R2-5 capstone: end-to-end silicon run -> receipts -> run-record -> citable verdict on the bench #7177, closed by PR verified: R2-5 capstone -- ternary_link run citation, silicon-proven end to end (Closes #7177) #7293 (squash b1951bb85, 2026-10-07).

Status 2026-10-08: every item above is landed; R2-3 via BrowserOS#537 (merged 2026-10-07 09:07:32Z).

These are requirements on the loop this epic already built, not new architecture.

Round-3 requirements (owner's decision 2026-10-07: "sign the receipts -- that is Round 3", translated)

Derived from a verifiable-compute competitor comparison (Gonka, Gensyn Verde, Prime Intellect TOPLOC, Hyperbolic PoSP, Nous Psyche, EigenAI, zkML, Phala/NVIDIA CC; table on #7332). t27's receipt carries the strongest content -- a bit-exact integer verdict, toolchain matched to the seal, agreement across placements -- and had the weakest envelope: unsigned, no challenge.

• R3-1 -- Signed receipts with a verifier nonce (Verified Compute R3-1: signed receipts with a verifier nonce (Ed25519) #7332). Ed25519 over a fixed message (domain + nine fields incl. the nonce); levels NONE < AUTHOR < FRESH; pre-rule receipts stay citable at NONE. Landed: contract PR verified: signed receipts with a verifier nonce -- R3-1 contract (Refs #7332) #7344 (specs/verified/signed_receipt.t27, squash e436d840a) + tool half PR verified: t27c signs receipts and run-record judges their level -- R3-1 tool half (Closes #7332) #7363 (t27c receipt-key init|show, silicon --nonce signs, run-record --challenge --require-level; merged 2026-10-07). No level is device-rooted yet -- that is R3-2.
• R3-2 -- Device-rooted identity. Read the 7-series 57-bit DNA_PORT live and bind it into the signed message; an IDCODE names the part, not the die, and a host key cannot tell two dies apart. Status 2026-10-08: contract + reader + tool on master (verified: the die's 57-bit DNA read over JTAG -- R3-2 slice 1 (Closes #7439) #7446, t27c: verify the die's DNA inside a signed receipt -- R3-2 slice 2 tool half (Refs #7452) #7484, t27c silicon: read the die's DNA into the signed receipt -- R3-2 slice 2, reader half (Refs #7452) #7570); the live run is citable: PR verified: the R3-2 live run is citable -- ternary_link re-sealed with built_by, three signed receipts naming die 050d58218fd9854 (Closes #7452) #7598 merged 2026-10-07 21:08Z (3/3 placements, FRESH, Die NAMED, run-record exit 0; receipts in .trinity/receipts/), R3-2 slice 2: the die's DNA as a signed receipt field (v2 message) #7452 closed. The DNA is a name, not a secret: no level is device-rooted.
• R3-3 -- Independence across boards/operators. Three seeds on one board catch place-and-route faults, not a dishonest operator; a citable run at the higher level needs agreement across distinct dies (measurable once R3-2 lands; three boards are on the bench).