Skip to content

Add controlled runtime verification - #10

Draft
200lz wants to merge 7 commits into
codex/p7b2-runtime-evidence-ingestion-20260815T060125Zfrom
codex/p7b3-controlled-runtime-verification-20260815T153049Z
Draft

Add controlled runtime verification#10
200lz wants to merge 7 commits into
codex/p7b2-runtime-evidence-ingestion-20260815T060125Zfrom
codex/p7b3-controlled-runtime-verification-20260815T153049Z

Conversation

@200lz

@200lz 200lz commented Aug 16, 2026

Copy link
Copy Markdown
Owner

Phase 7B.3 adds a controlled runtime verification path: a canonical controlled
request, plan, execution, evidence, and offline verification, bound to a stable
executable and loaded-artifact identity within a single pinned runtime profile.

Stacked on #9 (codex/p7b2-runtime-evidence-ingestion-20260815T060125Z), which is
itself stacked on #8.

What this changes

  • Canonical controlled request/plan/execution/evidence models and operations.
  • Stable executable and loaded-artifact identity binding.
  • Process completion separated from the output predicate and from OMIV stage
    status. Runner-authored text has no authority.
  • One absolute monotonic HTTP deadline; bounded IMAGE transport before
    allocation; bounded stdout/stderr collection.
  • Main-server and drafter-server support; CUDA, GPU, backend, offload,
    fixed-PNG, and drafter bindings; post-shutdown work inspection; controlled
    cleanup evidence.
  • Kernel whole-tree containment: setsid, setpgid, leader exit, double-fork,
    an atomic pre-exec gate, PID-namespace containment independent of /proc, and
    separate bounded binary supervisor channels for stdout and stderr.
  • Distinct derived loader ceilings — 112,272,128 request bytes, 137,437,952 plan
    bytes, 716,989,504 evidence bytes — replacing the previous shared 64 MiB
    ceiling. A 464,256,193-byte evidence object completes canonical write, load,
    and offline verification.
  • Descriptor-based bounded JSON reading, deterministic offline reconstruction,
    and privacy / no-partial-output enforcement.

Loader hardening in this change

Untrusted JSON pathnames are opened exactly once, atomically, with O_NOFOLLOW.
A platform lacking the flag, or a kernel rejecting it, fails closed before any
open or read, and the open is never retried without it. The previous
non-following stat fallback is removed: a following open after such a check can
be raced by replacing the pathname with a symlink to the same inode, which a
device/inode comparison would still accept. The fail-closed gate is evaluated on,
and returns, the exact value used as an open flag, so a non-integer, a boolean,
or a value that is truthy yet truncates to zero cannot admit a following open.

What this does NOT claim

This is the important part of this PR.

  • Synthetic success is not Muse success. The synthetic loopback fixture
    reaches five PASS stages, 4/4 probes, and VERIFIED_WITHIN_PROFILE. That
    exercises the machinery. It says nothing about any real model.
  • Muse Glimmer remains BLOCKED pending a real pinned GPU run. No Muse
    verdict is asserted by this change.
  • The Phase 7B.2 external observation remains PARTIAL and is unchanged here:
    five processes INCOMPLETE, all five runtime stages UNKNOWN, the fixed-PNG
    predicate OBSERVED rather than PASS, three artifacts
    MATCHED_PLAN_OBSERVATION, zero artifact payloads upgraded to verified from
    report prose, and drafter PNG and Ollama NOT_RUN.
  • External Phase 7B.2 evidence cannot produce the controlled verdict.
    Ingested external evidence is a planning input only; it is structurally
    incapable of yielding VERIFIED_WITHIN_PROFILE.
  • No performance, fidelity, safety, origin, publisher, certification, or
    production-readiness claim is added
    , and no claim of general Muse Glimmer
    compatibility or source-to-GGUF binding.

Any verdict this code can produce is scoped to one pinned runtime profile and to
the specific artifact and executable identities recorded in its own evidence.

Validation

Full hermetic offline suite: 2386 passed, 10 expected integration skips. Strict
mypy over 261 source files, ruff check, compileall, and git diff --check
all clean. Public-release-readiness audit: classification=PASS, 22/22 checks
passed.

An independent read-only review of the loader hardening recorded no P0/P1/P2
findings. Known residual P3 items are tracked as follow-up: the open precedes the
S_ISREG check so a directly named device node with open-time side effects is
not fully covered; three of the added no-follow tests also pass against the prior
code on Linux, so regression coverage for the removed race rests on the
missing-flag test; and several unrelated readers
(payload_integrity/observation.py, tokenizer_parity/observation.py,
provenance/loading.py, provenance/adapters.py,
tokenizer_parity/artifact_index.py, and two cli.py sites) retain weaker
symlink handling on independent code paths not reachable from this loader.

200lz added 7 commits August 16, 2026 17:57
Real llama.cpp answers every controlled endpoint with
"Content-Type: application/json; charset=utf-8". OMIV compared the recorded
response content type for raw equality against "application/json", so A6
Attempt 4 saw /health return HTTP 200 {"status":"ok"} 23 consecutive times and
still refused readiness with "controlled server readiness deadline expired".
RFC 9110 permits media-type parameters, so compare only the type/subtype.

Add one fail-closed is_json_media_type predicate and use it at all six response
sites: readiness, tokenize and completion on both the live execution path and
the offline verification path, so the two can never disagree about the same
evidence bytes. Outbound request-header invariants are unchanged.

The synthetic fixture emits a bare media type, which is why CI never observed
this class; the regression drives the fixture's single header site with the
llama.cpp form through the real controlled runtime and re-verifies the written
evidence offline.
@200lz
200lz force-pushed the codex/p7b3-controlled-runtime-verification-20260815T153049Z branch from 2fdd96b to 976aca8 Compare August 17, 2026 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant