A model-loading check can finish without a blocked operation and still leave the admission decision unresolved. For a platform leader, the useful question is what that observation rules out. If a suspicious branch never ran, repeating that the load was quiet does not explain why the artifact should be approved.
My design standard is to preserve the finding until there is evidence that addresses it. A REVIEW verdict should name the unresolved condition and make clear what another decision would depend on. Otherwise a cautious label can become a waiting room that nobody knows how to leave.
What the quiet load leaves open
Crucible, our Model Vetting Firewall demo, uses generated synthetic artifacts in a local registry. One conditional fixture contains builtins.eval, a callable identified by static inspection. During the observed load, its conditional behavior is not exercised and no blocked dangerous event is recorded. The configured gate returns REVIEW, with no signature.
The distinction matters because these checks answer different questions. Static inspection exposes a suspicious callable in the artifact. Behavioral observation reports the configured events encountered during this particular load. The absence of a blocked event cannot erase a static finding when the relevant branch was never exercised.
The synthetic conditional fixture remains in REVIEW because its suspicious branch was not exercised. REVIEW requests further evidence; it does not mean a human investigation is complete. The displayed scoreboard belongs to a fixed 33-fixture local synthetic capture using fresh configured checks and cached Codex advisory, not production performance.
The opposite mismatch also matters. In another synthetic fixture, PickleScan does not flag the artifact, but loading attempts a SQLite database operation. A configured CPython audit hook records and blocks that attempt, and the result is QUARANTINE. No database creation or persistence is established. A clean scanner result cannot cancel a recorded prohibited attempt any more than a quiet load can cancel an untested static concern.
These observations come from audit instrumentation in a Python subprocess. They do not demonstrate operating-system or container containment, exhaustive observation, or that arbitrary models are safe to load. The admission rule has to respect the evidence boundary of the worker that produced it.
Give REVIEW a resolution condition
For a production admission workflow, I would require the reviewer to address the specific unresolved finding before changing the decision. In the conditional example, that means explaining the suspicious callable, the condition governing its use, and whether the evidence covers the intended loading environment. Another uneventful run under the same conditions supplies little reason to close a branch that remained untested.
A team might replace the artifact with a separately reviewed data-only representation, or produce additional analysis and testing under appropriate isolation. Those are proposed paths for resolving uncertainty, not actions completed by this demo. Each path needs a stated reason why it answers the original concern. “The model loaded” is not that reason.
This also changes the handoff between security and platform teams. The review request should preserve the artifact hash, the finding, the observed events and the gate reason, so a later decision refers to the same bytes and the same unresolved question. The demo produces a downloadable evidence record containing those fields. It does not implement the enterprise review workflow or registry admission integration.
Approval and provenance remain separate
Even a configured ALLOW decision has a defined scope. The demo's synthetic clean weights dictionary receives ALLOW and an Ed25519 signature, using a local development key, over its model name, artifact hash and inventory payload. Only ALLOW receives that signature. Training-data provenance and fine-tuning history remain UNKNOWN.
That boundary matters to the reviewer deciding what can happen next. Evidence about the observed load does not establish upstream history. Signing the payload preserves a specific attestation relative to the local key; it supplies no missing training provenance. A production team would still need to decide which provenance requirements apply before approving use.
The Crucible breakdown explains the demonstrated checks and their limits. My criterion for an admission design is that every approval explains which concern was resolved, by what evidence, and which uncertainty remains. A quiet result becomes useful when we can say what it actually established.