Green is not a property of code. It is a relationship between a subject, an environment, a command, an observation and the authority allowed to use that observation. If one of those identities changes, the same green result may become supporting evidence, stale evidence—or no evidence for the gate at all.

A green run answers only the question it was bound and authorized to answer.

The gap was smaller than the temptation.

In the public PythiaLabs × Ota pressure test, two repairs targeted Windows-specific process boundaries. Both had passed inside a contributor fork. But the repository-owned workflows attached to the reviewed pull requests were Ubuntu-only.

source reviewed+fork run passed+upstream Windows not exercised→HOLD / NOT_RUN

The fork results were useful. They showed that the proposed branches could work on a hosted Windows runner. They could not, by themselves, become the repository-owned merge signal that the review boundary required.

Claim classification

V

Verified fact: both literal target SHAs ran on Windows, matched before and after execution, exited 0 and produced digest-bound artifacts.

B

Bounded inference: the exercised Windows-only code paths resolve the two observed portability failures at those exact revisions.

N

Not claimed: whole-project Windows compatibility, Ota adoption, merge approval or endorsement.

One temporary workflow. Two literal subjects.

Draft PR #269 added one disposable workflow to the repository. It did not touch either implementation branch. Each Windows job checked out its own literal 40-character SHA, asserted identity, ran only the affected surface, asserted identity again and uploaded a seven-day evidence packet.

01 checkout literal SHA
02 assert head before execution
03 run the smallest causal test on Windows
04 assert head after execution
05 retain log, exit status, runner and digest
#265 · MCPPASS
70d4a98a4801884b1c75df0166154e2d6d28853b

Command
node integrations/mcp/smoke.mjs

Observed
14 assertions passed · exit 0

Windows branch
mix.cmd, path.delimiter and Windows-only shell launch.

#266 · WorkerPASS
e62820c8f3a22ec6f26b027805e2a0ff1a73f509

Command
mix test test/port_worker_test.exs

Observed
solver_port.exe built · 3 tests · 0 failures · exit 0

Windows branch
Platform-specific executable selection and packet-framed port execution.

The receipts stayed attached to the claims.

The repository-owned workflow run 33766318986 completed successfully. Its two archives were downloaded and hashed; both matched the SHA-256 digests reported by GitHub.

PR #265 artifact1be6e23525275d0c51d765a480fda70d5a415d6b51b57921f8cc963fb1c7457b
PR #266 artifact2e4b25cc1e109b68bdc9e77fa80c03a4a790a6b0f095d0628ac1116844652bb3

The original GitHub artifacts expire on 10 September 2026. RESONANCE preserves a text evidence ledger and closed manifest alongside the provider archive digests. That preserves inspectability; it does not elevate archive integrity into proof of runner trust or test completeness.

The verdict changed on one axis.

BEFOREHOLD / NOT_RUN

No repository-owned execution had reached the Windows-specific branches.

AFTERWindows gate · PASS

Both affected surfaces passed on their exact reviewed revisions.

This is deliberately not a scalar approval. The run does not establish merge readiness, repository-global Ota governance, credentialed provider behavior, deployment correctness, multi-repository lifecycle behavior, production-wide Windows compatibility or the absence of unrelated defects.

The proof became stronger by refusing to become broader.

A portable pattern for exact-revision CI.

immutable subject→affected platform→smallest causal test→raw receipt→final identity check→bounded verdict

The reusable lesson is simple: evidence from another branch, fork, platform or workflow may reduce uncertainty, but it must not silently satisfy a gate whose authority and identity contract it does not meet.

Collaboration without implied endorsement.

This article records a public, bounded collaboration between PythiaLabs and Ota. Bobai, founder of Ota, proposed the pressure-test package and agreed to keep the reviewed implementation heads unchanged while the missing repository-owned Windows evidence was collected.

The attribution was approved in writing before publication. That approval acknowledges the stated contribution only; no merge approval, product endorsement or commercial claim is implied.

The Open Question

When may green evidence influence merge?

When CI replays code from another branch, fork or workflow, what exact identity and authority context must the result bind before it may influence a merge decision?

A useful answer should name one result that looks green but must still remain HOLD, NOT_RUN, STALE or INCOMPLETE.

Inspect the exact-head run →See the RESONANCE workflow model →

Primary / inspectable references

  1. PythiaLabs PR #265 — Windows MCP process portability
  2. PR #265 exact reviewed revision
  3. PythiaLabs PR #266 — Windows worker executable resolution
  4. PR #266 exact reviewed revision
  5. Temporary repository-owned Windows workflow PR #269
  6. Exact-head Windows workflow run 33766318986
  7. Bounded evidence verdict and artifact digests
  8. Canonical RESONANCE signal and claim boundary

Last evidence check: 4 September 2026. Public repositories and non-credentialed artifacts only. Participant attribution was approved in writing; no endorsement is claimed.