Model Admission Needs an Unresolved State

An AI model admission decision has to say what evidence permits the artifact to move forward. When a load produces no blocked event but static inspection still identifies a dangerous global, an approval compresses two different findings into one reassuring answer. I want the unresolved finding to survive the decision, with a clear account of what remains to be established.

We built Crucible, our local Model Vetting Firewall demo, around this distinction. It uses synthetic artifacts, including a file that a signature scanner does not flag but whose loading attempts a database operation, and another with a conditional branch that stays unexercised. The first demonstrates why an observed attempt matters. The second exposes the harder design problem: deciding what to do when the available checks disagree without pretending the disagreement has been settled.

The evidence changes the decision

In the synthetic database example, PickleScan does not flag the artifact. During loading, a configured CPython audit hook records and blocks an attempted SQLite database operation. The local pipeline returns QUARANTINE and issues no signature. The database operation did not succeed; the useful evidence is the attempted effect and its recorded block.

That gives the admission decision a reason the clean scanner result cannot supply. A team can point to the prohibited operation rather than asking the scanner's label to answer every question about the load. The scanner remains useful as a comparison, but its absence of a flag does not cancel an observed blocked attempt.

I prefer this separation because it makes the decision inspectable. A reviewer should be able to follow the relationship between a finding and an outcome. “The configured hook blocked this attempted database operation” is a bounded statement. It identifies the evidence, the mechanism and the reason for the local verdict. A broad safety label would leave those relationships hidden.

Observation also creates its own trust boundary. Here the worker attempts loading in a Python subprocess and watches configured audit events. That is demo instrumentation, with process separation, rather than operating-system or container containment. A production design would need to establish how the observation worker itself is isolated before trusting it with untrusted artifacts. Adding behavioral evidence does not remove the obligation to scrutinize the environment that collects it.

A quiet load leaves a harder question

The conditional synthetic fixture reaches a different outcome. Static inspection finds builtins.eval, a global on the demo's configured dangerous list. The observed load records no blocked dangerous event because the conditional branch is not exercised in this environment. The pipeline routes the artifact to REVIEW, with no signature. No human investigation has been completed by that route.

There are three defensible responses to consider, and each spends something different. Approval accepts the uncertainty. Rejection avoids using this artifact but can discard something a narrower investigation might explain. Further review delays the decision and requires someone to define what additional evidence could change it.

For this case, I prefer review because the uncertainty is specific. There is an identified static concern and an identified gap in observation. The quiet run does not explain why the dangerous global is present or what happens if the branch is reached. Approval would require accepting that gap. Immediate rejection could be a reasonable organizational policy, but it would be a choice to exclude the artifact on unresolved static evidence, rather than proof that a prohibited effect occurred.

The distinction matters when a team writes its admission policy. A failure to observe an effect should not silently become a finding that the effect cannot occur. Likewise, suspicion should not silently become evidence of a successful attack. REVIEW provides a place to retain both facts while the organization chooses how much uncertainty it can accept.

REVIEW needs an exit criterion

A review status alone can become an expensive holding area. It earns its place only when the record explains the unresolved question and the next decision someone has to make. In this example, the question concerns the static global and the unexercised branch. Repeating the same quiet load without changing what is investigated would add another observation without answering that question.

In a hypothetical enterprise process, a team might inspect the branch, seek a trustworthy explanation from the artifact's supplier, or choose a replacement artifact with a more inspectable loading path. Those are proposed responses, not workflows this demo completes. Each has a cost: deeper inspection requires expertise, supplier evidence requires its own validation, and replacement may sacrifice needed functionality. The choice depends on which evidence the team can obtain and which uncertainty its policy permits.

I want that choice to be explicit. If no available investigation can resolve the concern within the team's constraints, rejecting the artifact may be the appropriate end of review. REVIEW should not promise that every file eventually earns approval. Its purpose is to keep an unresolved question from disappearing into a verdict and to make the eventual decision accountable to a stated policy.

The same discipline applies to AI explanation. In the demo, a combined analyst and challenger advisory can add caution and move a base ALLOW result to REVIEW; it cannot remove QUARANTINE. The recorded presentation uses cached Codex advisory alongside fresh configured checks. One synthetic reference record illustrates the danger of treating narrative as authority: its advisory recommends signing and promotion, while the final structured outcome is REVIEW and no signature is issued.

An admission consumer should therefore read the structured verdict, gate reason and actual signature field. Helpful prose can explain a decision, but the prose must not become a second, conflicting permission to move an artifact forward. A review process that trusts the recommendation sentence over the final gate has lost the distinction it was meant to preserve.

Approval has a boundary too

The synthetic clean weights dictionary receives ALLOW and a signature over its model-name, artifact hash and inventory payload using a local development key. Its training-data provenance and fine-tuning history remain UNKNOWN. Only ALLOW receives that signature; REVIEW and QUARANTINE do not.

This matters for the exit from review as much as for the clean path. Resolving a loading concern would not, by itself, establish training history. A signature can authenticate the specified local payload relative to its key while an upstream question remains unanswered. A team should ask separately whether the admission evidence is sufficient for the loading decision and whether the missing provenance is acceptable for the intended use. One approved check should not settle a question it never examined.

The Crucible explainer shows these local examples and their evidence. Registry integration, enterprise admission enforcement and production signing custody remain work beyond this demo. Its value is the decision boundary it makes visible, rather than a claim that the local implementation supplies all the controls an enterprise would need.

Here is the founder video showing the local synthetic model-vetting demo.

For a platform team evaluating an admission design, I would start with the case whose evidence does not line up neatly. Ask what keeps the unresolved finding visible, who decides whether more investigation is worth its cost, and what evidence can change the outcome. A clean path is easy to describe. The unresolved path reveals whether the system preserves uncertainty long enough for a responsible decision to be made.