PROJECT BRAIN VAL BRIDGE PROTOCOL V2

Normal ChatGPT project work uses Val Town as the only ChatGPT-facing transport to the canonical Project Brain. Direct Sprites connector calls are maintenance-only because they can trigger separate file-materialization approval prompts.

Normal path:

ChatGPT → Val Town → brain_bridge_jobs → authority-selected Brain executor → canonical Brain

Val/project: mosadek/project-brain-live-v1-durable
Queue: brain_bridge_jobs
Control-plane authority: brain_control_plane_authority_v1

At epoch 2 the live canonical writer is currently val_native. The historical host worker identity project-brain-live-v1-worker-v2 remains compatibility evidence, not current writer authority.

The HTTP endpoint being reachable is NOT proof that the authority-selected Brain executor is alive.

brain_bridge_worker.ts /health is the historical host-bridge worker health surface. Its worker_state applies only to that host worker. Read control_plane_authority.writer before interpreting it:

• if writer is host_bridge, HTTP 200/503 and worker_state are relevant to canonical executor liveness;
• if writer is val_native, a stale host heartbeat does NOT mean the canonical control plane is down;
• endpoint_ok:true only proves the Val endpoint itself is executing;
• worker_health_scope:HOST_BRIDGE_WORKER_ONLY is an explicit interpretation fence;
• instance_identity_available:false means the historical host worker has not supplied a distinct process instance ID. Do not overclaim process identity;
• canonical status/chain/claim-graph receipts remain the authoritative proof of Brain state reached through the current writer path.

Current Val-side invariants:

• priority cap: 1_000_000_000;
• selection above the cap: FIFO by created_at,id;
• maximum Brain command timeout: 120 seconds;
• queue lease: 180 seconds;
• atomic single-flight per worker_id;
• an active unexpired lease is not redelivered to another poll sharing that worker ID;
• a pre-existing duplicate active lease for one worker ID fails closed;
• expired queue leases are terminalized FAILED on a worker poll with TRANSPORT_LEASE_EXPIRED_OUTCOME_UNKNOWN; they are not automatically returned to READY;
• an expired/unknown attempt must be reconciled against canonical state before any retry is submitted under a new job ID;
• results are accepted only for the current unexpired lease owner.

These are transport invariants, not Brain authority.

Canonical Brain integrity and independently verified replica durability are separate facts.

The worker health body exposes:

• durability.canonical_generation;
• durability.max_verified_replica_generation;
• durability.verified_replica_count;
• durability.lag_generations;
• durability.state = CURRENT | LAGGING | UNKNOWN.

Interpretation:

• a canonical generation newer than the latest verified replica is valid canonical progress, but it is NOT fully replicated durability;
• never report fully durable while lag_generations > 0;
• durability lag does not by itself invalidate read-only canonical status/verification;
• before destructive cleanup, authority transition, or a claim whose consequence depends on recoverability, explicitly account for the lag and preserve consequential evidence first;
• never hide durability lag by reading an older replica as though it were current canonical state.

The Brain kernel keeps the strict expected-workstream-generation commit guard, and the epoch-2 Val-native executor keeps the authenticated queue payload_json byte-identical for the lifetime of one transport attempt. Production does not transparently rewrite a commit payload to inject a fresher generation.

To prevent admission churn from starving an already-READY commit, the transport selector applies a bounded commit-position barrier. A valid READY status, verify-chain, verify-claim-graph, register-agent, or claim job may not leapfrog a valid READY commit that is older by created_at, with rowid breaking same-timestamp ties. recover-stale remains recovery-first. Admission/read jobs genuinely older than the commit retain their existing place, and the same-second register-before-claim invariant remains unchanged.

This barrier does not declare unrelated canonical mutations semantically harmless. If an earlier mutation legitimately advances the workstream before a commit executes, the strict kernel may still return STALE_WORKSTREAM_WRITE; the caller must reconcile canonical state and submit a new job ID with a fresh expected generation. The bounded guarantee is narrower and auditable: later boot/read admission traffic cannot indefinitely leapfrog an older READY commit. Exact job, lease instance, lease attempt, transport generation, authority epoch, payload identity, task lease, dependency/guard/write semantics, and duplicate-terminal fences remain unchanged.

Historical evidence for the earlier task-local stable-retry design remains at valblob:mosadek/project-brain-live-v1-durable/evidence/control_plane/val_native_stable_commit_retry_v1.json, including its independent artifact_present falsification and repair. That mechanism is historical evidence, not the current production dispatch behavior.

Insert a unique job:

INSERT INTO brain_bridge_jobs
(id, priority, op, payload_json, state, lease_owner, lease_expires_at,
 result_json, error_json, created_at, updated_at)
VALUES (?, ?, 'brain', ?, 'READY', NULL, NULL, NULL, NULL,
        datetime('now'), datetime('now'))

Brain payload is closed-schema:

{"args":["status"],"timeout":60}

Requirements:

• exact top-level keys: args, timeout;
• args is a non-empty string array;
• timeout is an integer from 1 through 120;
• status, verify-chain, and verify-claim-graph take no additional Brain arguments;
• renew-lease uses canonical --seconds; stale --lease-seconds is rejected fail-closed;
• boot, boot-agent, recover-leases, unsupported artifact commands, and payloads with extra top-level fields are not compatibility aliases.

Recognized Brain subcommands at the bridge syntax layer:

• status
• verify-chain
• verify-claim-graph
• register-agent
• ensure-task
• delegate-task
• claim
• renew-lease
• commit
• checkpoint
• add-claim
• invalidate-claim
• supersede-task-context
• migrate-task-invariants
• reconcile-causal-blocks
• recover-stale

Do not confuse recognized with currently executable.

While control-plane authority is epoch-2 val_native, the current atomically qualified execution surface is exactly:

• read-only: status, verify-chain, verify-claim-graph;
• mutation: register-agent, ensure-task, claim, renew-lease, commit, recover-stale.

The remaining recognized mutators are implemented but deliberately fail closed with VAL_NATIVE_MUTATOR_NOT_YET_ATOMICALLY_QUALIFIED until an independently verified reactivation changes the canonical Val-native allowlist. Clients MUST NOT enqueue them merely because the syntax layer recognizes their names. Re-read the current authority-selected executor before relying on a newly reactivated mutator.

Anything outside the recognized syntax surface fails at Val-side dispatch rather than being sent onward.

There is currently NO valid atomic boot bridge command.

The public bridge previously advertised boot, but the live kernel accepts boot-agent while the persistent executor rejects raw boot-agent. Therefore neither spelling is a valid end-to-end bridge operation.

Use the proven equivalent sequence:

1. register-agent
2. claim

The transport selector preserves a same-second paired bootstrap invariant: when READY register-agent and claim jobs have the same created_at and exact agent identity, the registration is selected before its claim even if the claim has a higher submitted priority. Clients must not depend on priority to reverse that order.

Register only capabilities actually present in the current chat. Never claim human_authority_approval.

Example conceptual sequence:

register-agent <unique-agent-id> --workstream <ws> --role <role>
  --type CHAT --capabilities <json-array>

claim --agent <unique-agent-id> --mode INTERACTIVE --lease-seconds 1800

Do not submit boot or boot-agent until a later verified bridge/executor revision explicitly restores an atomic wrapper.

Canonical Brain task-lease recovery is exposed through exactly one bridge spelling:

{"args":["recover-stale"],"timeout":60}

Requirements:

• the Brain subcommand is exactly recover-stale;
• args contains exactly that one string and no additional arguments;
• timeout remains an integer from 1 through 120;
• recover-leases is intentionally rejected and is not an alias;
• unknown recovery spellings fail closed at Val-side dispatch.

Val transport queue-lease expiry remains a separate transport mechanism. The worker detects expired transport attempts on poll and terminalizes them FAILED with unknown canonical outcome; it does not treat transport expiry as proof that the Brain command had no effect.

End-to-end evidence: queue job chat-sol-20260906-0139-recover-stale-v5-z91 completed through the persistent V5 worker at Brain generation 1321 and recovered three expired canonical task leases. This establishes the current recovery path; it does not prove permanent executor liveness or transport attempt-fencing.

SELECT id,state,lease_owner,lease_expires_at,result_json,error_json,updated_at
FROM brain_bridge_jobs
WHERE id=?

Terminal states:

• COMPLETE
• FAILED

A READY job means it has not been executed. A LEASED job is not complete. Do not infer canonical mutation from queue state alone.

The currently authoritative epoch-2 val_native executor accepts only op='brain'. It rejects queue op='read_text' with VAL_NATIVE_UNSUPPORTED_TRANSPORT_OP.

Therefore while brain_control_plane_authority_v1.writer='val_native':

• DO NOT enqueue read_text jobs for /brain/JOIN_PROTOCOL.md or artifacts;
• read Val-hosted project source/protocol files through the connected Val Town file tools;
• obtain canonical Brain state through the allowed brain commands and bounded project-controlled read-only canonical views;
• do not convert a missing transport read operation into a reason to call Sprites.

The historical host bridge still contains a bounded read_text implementation for compatibility. It is eligible only if host_bridge is again the authoritative writer and the exact current executor path is independently shown to support it. Historical successful reads do not establish epoch-2 support.

Routine ChatGPT work:

• DO NOT call Sprites;
• DO NOT call Sprites.exec;
• DO NOT call Sprites.file_read/file_write/file_copy/file_delete;
• DO NOT call Sprites service/checkpoint/file/blob operations.

If a required operation is missing:

1. use an existing valid non-Sprites substrate when possible;
2. route or build a bridge extension;
3. fail closed if the missing operation is necessary;
4. direct Sprites remains an explicit maintenance emergency, not an automatic fallback.

If jobs stay READY:

1. inspect /health;
2. inspect worker endpoint traces;
3. inspect the current active/expired queue leases;
4. do not raise transport priorities above the cap to win a queue arms race;
5. do not interpret the Val endpoint being online as the Brain worker being online.

If worker health is DOWN:

• queued commands remain pending;
• no live Brain registration, claim, commit, status, or verification should be invented;
• Val-side code/evidence work may continue when it does not pretend to mutate canonical Brain;
• repair/restore the persistent executor through an authorized route, then resume queue processing.

The reverse bridge has successfully:

• read Brain status;
• created canonical Brain tasks;
• registered CHAT agents;
• claimed tasks;
• committed task results;
• run verify-chain and verify-claim-graph.

The Val-side worker has independently reproduced and repaired the same-worker concurrent lease race in isolated queue tests. This does NOT prove the persistent Sprite-side executor is permanently supervised or continuously alive.

Normal ChatGPT/Brain work MUST NOT create one Val Town branch per agent.

Use task-scoped project blobs for scratch/evidence first. Use task-namespaced files on main only when shared executable/source bytes are necessary and the Brain task's declared write-resource lease permits them. Use a bounded reusable scratch branch only when branch isolation is causally required. A net-new branch requires an explicit task need, a branch-headroom check, and a preservation/cleanup plan.

Do not delete a branch merely because it is old, low-version, or apparently merged. Before deletion apply VAL_BRANCH_LIFECYCLE_POLICY_V1.md; any unresolved dependency or unique-evidence question means KEEP.

The scaling invariant is:

d(live_branch_count) / d(agent_count) = 0

This keeps the reproduced Val Town branch ceiling out of the normal agent-admission path.

Normal project work must stay materialization-free from ChatGPT while remaining fail-closed:

ChatGPT agent → Val Town → durable queue → live worker → verified Brain

If the live worker disappears, the system must say so rather than smiling with HTTP 200 like a malfunctioning status page.