SAFE-PRUNE / DEFER decision policy
A partial engine can expose only two safe online outcomes: exact rejection or defer-to-baseline.
Diagnostic work, exact algebra and local capabilities are not treated as end-to-end mining advantage.
What was tested?
A partial engine can expose only two safe online outcomes: exact rejection or defer-to-baseline.
Why the test is meaningful
A partial proof-of-work engine must be one-sided: it may reject only when failure is mathematically certain. Anything not proven impossible must return DEFER so the conventional baseline remains responsible for the final decision.
SAFE_PRUNE(x) ⇒ PoW(x)=falseDEFER(x) ⇒ evaluate baseline; it does not imply successfalse-reject count = |{x:SAFE_PRUNE(x) ∧ PoW(x)}|How it was tested
Formalize SAFE-PRUNE certificates, route all unproven cases to DEFER and audit the combined policy against full hashing.
What happened
The policy preserved exactness: only proven impossibilities were pruned; every unresolved candidate remained eligible for baseline evaluation.
Exactness and statistical controls
Every emitted prune was checked against full hashing, and every unresolved state remained on the baseline path. The key safety statistic is false rejects, not the fraction pruned; the registered value was zero.
What the result means
DEFER is a safety property, not failure. It prevents a partial relation from silently creating false negatives.
Limitations
- A safe policy may defer too often to be useful.
- Certificate-generation cost is not removed by a correct interface.
- Zero observed violations is scoped to the tested certificate family.
Evidence trail
Certificate verification and end-to-end decision comparison are deterministic.
Canonical variants
SUBENGINE-V7ASUBENGINE-V7BSUBENGINE-V7CSUBENGINE-V7DSUBENGINE-V7ESUBENGINE-V7FSource: internally audited canonical reports. Local filesystem structure, private headers and operational identifiers are excluded from publication.