Skip to content

policy(oracle): admit a pinned secondary oracle where vLLM implements nothing (#647) - #650

Merged
mudler merged 1 commit into
mainfrom
row/ENG-ORACLE-PIN-REGISTRY
Aug 13, 2026
Merged

policy(oracle): admit a pinned secondary oracle where vLLM implements nothing (#647)#650
mudler merged 1 commit into
mainfrom
row/ENG-ORACLE-PIN-REGISTRY

Conversation

@localai-bot

Copy link
Copy Markdown
Collaborator

Closes #647.

AGENTS.md said comparisons run against "the pinned oracle" and pointed at
upstream-sync.md, which pins exactly one thing: vLLM. This repository already
compares itself against five other upstreams, and every one of their pins lives
somewhere else or nowhere.

Upstream Pin before this PR
vLLM-Omni none at all (#633) — H3 W3+, LTX-2.5 and ~40 omni-only architectures have no oracle
SGLang v0.5.15/f63458b5 in sglang-matrix.md and v0.5.13/28b095c0 in cuda-sglang-low-concurrency.md, with nothing making the difference visible from either
llama.cpp 237ad9b96 (b9892), repeated across six CPU specs
transformers 5.14.1, recorded only as a component of the vLLM env line
tt-forge nowhere, though BACKEND-TENSTORRENT is ACTIVE on real Blackhole and porting-inventory.md:1004 already states vLLM has no Tenstorrent platform anywhere

So the rule had no answer for a model vLLM does not implement at all.
MiniMax-Music3 (minimax_music3, served by SGLang-Omni and diffusers) is
the case that surfaced it: scoping stalled on a policy question, not an
engineering one.

What changes

Policy. AGENTS.md gains §"When vLLM has no implementation": vLLM stays
primary and wins every disagreement; a secondary oracle is admissible only from
a fixed table and only at a recorded pin; it never becomes the mirror source;
the row reconciles onto vLLM when vLLM implements the path. Gateability keeps
the primary's rule — gateable once it demonstrably builds and runs the model.

Pin surface. .agents/oracles/<id>.md, one file per oracle, read by
glob
. A shared table would be a lock: two rows advancing two pins in one week
conflict on lines neither owns. vllm.md deliberately does not restate the
parity pin's meaning — upstream-sync.md keeps it, because a value transcribed
twice drifts, which is the defect this registry removes rather than re-imports.

Enforcement. scripts/check-oracle-pins.py + --self-test + a unit suite,
wired into agent-preflight.sh and CI. It requires all nine keys non-empty with
no undefined key, exactly one role = primary and that one vllm, and the
AGENTS.md table and the directory to name the same ids in both directions.
gateable = yes demands a non-UNPINNED revision and evidence that is a path
existing in the tree; an issue number is refused there and required in the other
direction.

Evidence

Three mutations performed against the live registry, not asserted about:

Mutation Result
flip sglang to gateable = yes red — "an issue is a promise of a measurement, not one"
delete the tt-forge row from the AGENTS.md table red — "pinned in .agents/oracles/ but absent from the AGENTS.md table"
repoint llama-cpp evidence at a nonexistent path red — "evidence path does not exist in this tree"

Tree restores byte-for-byte after each. The unit suite performs the same drop
for every required key one at a time, so the key list cannot outgrow its
enforcement; --self-test sweeps 11 fixtures in both directions. 24 tests pass.

The live checker found a real defect during development — the id regex matched
the table's own backticked header cell — which is why the header now reads
Registry id.

Honest limits

The checker is network-free and never verifies a pin exists upstream (a
fabricated 40-hex passes shape and fails review). It does not reconcile
vllm.md against upstream-sync.md, since teaching it to sync two
transcriptions would bless the duplication. The **Secondary oracle:** check is
opt-in by syntax — a checker firing on the word "SGLang" would red hundreds of
innocent specs and be silenced within a week.

Five of seven records say gateable = no, which is the honest reading, not
a gap in the work: vLLM-Omni and diffusers have never been executed here,
SGLang has been read but never run (its parity spec is explicitly "no
measurement taken here"), and tt-forge needs Blackhole silicon. Only vLLM and
llama.cpp carry measured evidence; transformers carries the AUDIO A0 goldens
captured from it. Those debts stay open on #647.

tt-forge scan, since admitting an oracle is a claim: it executes models end
to end over TT-Metalium across three frontends with 800+ variants in CI, so it
is a reference to run, not merely a stack to read. tt-forge-models gets no
record — it supplies ForgeModel loaders and publishes no reference outputs and
no PCC comparison, so it is a source of subjects, named in tt-forge's scope.
ttnn is not an oracle either: our backend calls it, and an oracle is something
we compare against.

Exception argued, not hidden: this skipped the fresh-reviewer round trip on
explicit developer direction to add the policy immediately and merge it
directly. Compensating evidence is the mutation set plus full preflight; nothing
here touches src/ or a gate's numeric semantics.

Gate

scripts/agent-preflight.sh — all checkers and all suites ok except
test_cpu_x86_llamacpp_floor, a contention-sensitive harness that failed
identically (NO_QUIET_WINDOW, exit 4) on an unmodified tree at base SHA
cefacd2d0
under load average 35. Pre-existing and environmental, verified
rather than assumed.

🤖 Generated with Claude Code

… nothing (#647)

AGENTS.md said comparisons run against "the pinned oracle" and pointed at
upstream-sync.md, which pins exactly one thing: vLLM. Meanwhile this repository
already compares itself against five other upstreams, and every one of their
pins lives somewhere else or nowhere:

  vLLM-Omni    no pin at all (#633), so H3 W3+, LTX-2.5 and ~40 omni-only
               architectures have no oracle to be gated against
  SGLang       v0.5.15/f63458b5 in sglang-matrix.md, AND v0.5.13/28b095c0 in
               cuda-sglang-low-concurrency.md -- two revisions, two specs, and
               nothing that makes the difference visible from either one
  llama.cpp    237ad9b96 (b9892), repeated across six CPU specs
  transformers 5.14.1, recorded only as a component of the vLLM env line
  tt-forge     nowhere, though BACKEND-TENSTORRENT is ACTIVE on real Blackhole
               and porting-inventory.md:1004 already states that vLLM has no
               Tenstorrent platform anywhere

So the rule as written had no answer for a model vLLM does not implement at
all. MiniMax-Music3 (`minimax_music3`, served by SGLang-Omni and diffusers) is
the case that surfaced it: scoping it stalled on a policy question rather than
an engineering one.

WHAT CHANGES. AGENTS.md gains "When vLLM has no implementation": vLLM remains
primary and still wins every disagreement, a secondary oracle is admissible only
from a fixed table and only at a recorded pin, it never becomes the mirror
source, and the row reconciles onto vLLM when vLLM later implements the path.
Gateability keeps the primary's rule -- an oracle is gateable once it
demonstrably builds and runs the model, and until then its record says so and
names the issue that owes the measurement.

THE PIN SURFACE IS ONE FILE PER ORACLE, read by glob. A shared table would be a
lock: two rows advancing two pins in one week conflict on lines neither owns,
and an automatic three-way merge of a keyed record is what the protocol refuses.
vllm.md deliberately does NOT restate the parity pin's meaning; upstream-sync.md
keeps it, because a value transcribed twice is a value that drifts -- which is
the defect this registry was written to remove, not one to re-import.

ENFORCEMENT, because a rule nobody runs is prose. check-oracle-pins.py requires
every record to carry all nine keys non-empty with no undefined key, exactly one
role=primary and that one vllm, and the AGENTS.md table and the directory to
name the same ids IN BOTH DIRECTIONS -- an oracle cannot be admitted in prose
without a pin, nor pinned in a file nobody may use. gateable=yes demands a
revision that is not UNPINNED and evidence that is a path EXISTING IN THIS TREE;
an issue number is refused there and required in the other direction, so an
ungateable lane is visible debt rather than a mid-campaign discovery.

Three mutations were performed against the live registry, not asserted about it:
flipping sglang to gateable=yes, deleting the tt-forge row from the AGENTS.md
table, and repointing llama-cpp's evidence at a nonexistent path. All three go
red; the tree restores byte-for-byte. The unit suite performs the same for every
required key one at a time, so the key list cannot outgrow its enforcement, and
--self-test sweeps 11 fixtures in both directions.

WHAT THE CHECKER DOES NOT DO, so nobody cites it for more: it is network-free
and never verifies a pin exists upstream (a fabricated 40-hex passes shape and
fails review); it does not reconcile vllm.md against upstream-sync.md, since
teaching it to sync two transcriptions would bless the duplication; and the
`**Secondary oracle:**` check is opt-in by syntax, because a checker that fired
on the word "SGLang" would red hundreds of innocent specs and be silenced within
a week.

SCAN RESULT ON tt-forge, since admitting an oracle is a claim. It executes
models end to end over TT-Metalium across three frontends with 800+ variants in
CI, so it is a reference to run and not merely a stack to read -- that is what
qualifies it. tt-forge-models is NOT given a record: it supplies ForgeModel
loaders and publishes no reference outputs and no PCC comparison, so it is a
source of subjects, named in tt-forge's scope. ttnn is not an oracle either --
our backend calls it, and an oracle is something we compare against.

FIVE OF SEVEN RECORDS SAY gateable = no, and that is the honest reading rather
than a gap in the work: vLLM-Omni and diffusers have never been executed here,
SGLang has been read but never run (its parity spec is explicitly "no
measurement taken here"), and tt-forge needs Blackhole silicon. Only vLLM and
llama.cpp carry measured evidence; transformers carries the AUDIO A0 goldens
captured from it.

EXCEPTION ARGUED, NOT HIDDEN: this skipped the fresh-reviewer round trip on
explicit developer direction to add the policy immediately and merge it
directly. The compensating evidence is the mutation set above plus full
preflight; nothing here touches src/ or a gate's numeric semantics.

Gate: scripts/agent-preflight.sh -- all checkers and all suites ok EXCEPT
test_cpu_x86_llamacpp_floor, which is a contention-sensitive harness and failed
identically (NO_QUIET_WINDOW, exit 4) on an unmodified tree at the base SHA
cefacd2 under load average 35. Pre-existing and environmental, verified rather
than assumed.

Issue: #647

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
@mudler
mudler merged commit b81a5e4 into main Aug 13, 2026
13 of 18 checks passed
@localai-bot
localai-bot deleted the row/ENG-ORACLE-PIN-REGISTRY branch August 13, 2026 17:57
localai-bot pushed a commit that referenced this pull request Aug 13, 2026
FOLLOWING_AGENTS_PROTOCOL

main advanced to b81a5e4 (#641's LTX-2.5, then #650's oracle policy) and
roadmap_v1.md's Open-issues table conflicted. That table is a KEYED RECORD, so
AGENTS.md forbids resolving it by automatic three-way merge: took main's file
WHOLESALE and reapplied this branch's two scoped edits.

The two edits are NOT the same operation, and treating them alike is the trap I
walked into first. #608 already exists on main -- it landed via #612 -- so it is an
UPDATE IN PLACE. #649 is new, so it appends. My first attempt appended both and
produced a duplicate #608, caught by counting rather than by any gate: the
uniqueness check the checker does run would have caught it too, but only after I
had already written the wrong thing.

Verified rather than asserted: diff against main is +2/-1 -- one row replaced, one
added -- and grep gives exactly one #608 row and one #649 row.

One gate needed a second look. test_cpu_x86_llamacpp_floor's contended-leg case
failed once here at load 26.97, then passed twice consecutively in this same
worktree, and passes on clean main at the same load; the test file and tools/bench
are byte-identical to main. That is #618's known flakiness, not this resolution.
Re-ran the full staged gate afterwards for a clean result rather than reasoning
past the red.

scripts/agent-preflight.sh --staged: exit 0, all gates green.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
localai-bot pushed a commit that referenced this pull request Aug 13, 2026
FOLLOWING_AGENTS_PROTOCOL

This branch was based on a20cdac and main has since reached 67e53e7 -- #641's
LTX-2.5, #650's oracle policy, and #643's own tool-parser backfill. roadmap_v1.md
conflicted.

Resolved by the keyed-record rule rather than by three-way merge: took main's file
WHOLESALE, then reapplied this branch's two edits IN PLACE -- the #607 issue row
and the recipe-sweep table's --language-model-only line, both of which existed
already and both of which this branch UPDATES rather than adds. Diff against main
is +2/-2, exactly two replacements and no additions.

The reason wholesale mattered here and not just as ceremony: this branch's tree
still carried the PRE-CORRECTION #608 row, which said four of the five parsers
were portable at the pin. #643 has since corrected that to "only inkling is
portable from vLLM source". An automatic merge would have been free to keep either
side; taking main's file wholesale means the corrected row is the one that
survives, and I checked that it did rather than trusting the mechanism.

Exactly one #607 row and one #608 row afterwards.

scripts/agent-preflight.sh --staged: exit 0, all gates green.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
localai-bot pushed a commit that referenced this pull request Aug 13, 2026
…nded (#633)

FOLLOWING_AGENTS_PROTOCOL

#650 landed the oracle registry while this row was open, and it is a better
answer to this row's problem than the one this spec proposed. The first draft put
an `omni-parity-pin` block inside `upstream-sync.md`; the registry puts one file
per oracle under `.agents/oracles/`, read by glob, and explicitly rejects the
shared-surface shape the draft had. So the spec is rewritten rather than patched,
and says at the top that it was superseded.

What this row no longer does: propose a record format, restate per-architecture
gateability (AGENTS.md and `oracles/README.md` already bind it), or touch
`.agents/oracles/vllm-omni.md` at all — that file already reads `pin = UNPINNED`,
`gateable = no`, `evidence = #633`, which is exactly true.

What survives is what the registry file cannot state on its own: the two pins may
legitimately DISAGREE (vllm-omni requires vLLM 0.27.0+ against our 0.26.0.dev0
parity pin), an omni-gated number is therefore labeled with BOTH commits and is
never evidence about the core pin's surface, and an omni pin advance does not
re-open the vLLM-side binding grids provided the omni oracle is isolated in its
own virtualenv. `upstream-sync.md` now points at the registry and carries only
those rules.

`core_commit_used` is deliberately NOT added to the `oracle-pin` schema here. The
pin is UNPINNED, so there is no value to record, and extending a checker-enforced
schema for a value that does not exist is speculation. It lands with the
measurement as W4, with its own mutation evidence.

Merge resolution: main had moved `PARTIAL` 16 -> 17 and `INVENTORIED` 39 -> 38;
this branch's one READY row is reapplied on top of those numbers rather than
either side being taken whole.

Gates: preflight green except `test_cpu_x86_llamacpp_floor`, which exits 4
(NO_QUIET_WINDOW) at load 74-103 while another session builds LTX-2.5 on this
box. It never measured anything; base-SHA comparison recorded on the PR.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
localai-bot added a commit that referenced this pull request Aug 13, 2026
…633) (#635)

FOLLOWING_AGENTS_PROTOCOL

The pin protocol covered one repository, so every architecture living only in
`vllm-project/vllm-omni` had no oracle it could be gated against. #650 landed the
oracle registry mid-flight and superseded this row's original design (a second
pin block inside `upstream-sync.md`), so the spec was REWRITTEN onto the registry
rather than patched, and says so at the top.

`.agents/oracles/vllm-omni.md` is deliberately untouched: it already reads
`pin = UNPINNED`, `gateable = no`, `evidence = #633`, which is exactly true.
`upstream-sync.md` now points at the registry and carries only what the registry
file cannot state on its own — that the two pins may legitimately DISAGREE
(vllm-omni requires vLLM 0.27.0+ against our 0.26.0.dev0 parity pin), that an
omni-gated number is therefore never evidence about the core pin's surface, and
that an omni pin advance does not re-open the vLLM-side binding grids provided
the omni oracle is isolated in its own virtualenv.

`core_commit_used` is deliberately NOT added to the checker-enforced schema: the
pin is UNPINNED, so there is no value to record. It lands with the measurement.

`ENGINE_ROWS` 153 -> 154, with mutation evidence that is load-bearing against the
exact bad merge this branch hit: main bumped the same constant 152 -> 153 for a
different row, so both sides read 153 and the merge looked clean. Drop the row,
rewind the constant and the rollup until every count agrees, and 1 of 53 tests
fails: that one.

NO product code. This is a spec and its records.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants