ontocast.tool.facts_validation.acceptance¶
What counts as a blocking defect in a rendered unit graph.
The facts loop used to accept a render on critique.success or
critique.score > 90 -- an LLM-assigned 0-100 score compared against a
threshold the model is never shown, from a prompt that never mentions scoring at
all. An LLM asked to propose improvements proposes some every time, and scores
itself into a middling band while doing so, so the gate rejected nearly every
render and was very nearly unconditional.
Worse, it was inverted. deterministic_findings -- machine-derived,
verifiable, carrying an explicit mandatory flag -- was computed before every
critic call and injected into the critic's prompt, then played no part in the
decision. A unit with twelve mandatory UNKNOWN_TERM findings was accepted if
the model said so; a unit with none was rejected if the model said 85. Most
units carried no mandatory finding at all when the critic ran, so they were sent
for a full re-render on the strength of a number alone. The expensive action was
bound to the unreliable signal and the cheap one to the reliable signal.
Acceptance is therefore decided here, from defects that can be pointed at.
Attributes¶
BlockingFixSeverity = Literal['critical', 'important', 'never']
module-attribute
¶
Classes¶
FactsAcceptancePolicy
¶
Bases: BaseModel
Which defects block a rendered unit from leaving the loop.
Attributes:
| Name | Type | Description |
|---|---|---|
blocking_finding_kinds |
frozenset[str] | None
|
Finding kinds that block. |
blocking_fix_severity |
BlockingFixSeverity
|
The cut applied to critic-proposed fixes.
|
Source code in ontocast/tool/facts_validation/acceptance.py
Attributes¶
blocking_finding_kinds = None
class-attribute
instance-attribute
¶
blocking_fix_severity = 'critical'
class-attribute
instance-attribute
¶
Methods:¶
blocks_finding(finding)
¶
True when this deterministic finding must be repaired before exit.
Typed on the shared base, and matched on the kind's value, so one policy serves both phases: the facts and ontology finding kinds are separate enums with no member in common, and the alternative was a second policy class differing only in an annotation.
Source code in ontocast/tool/facts_validation/acceptance.py
blocks_fix(fix)
¶
True when this critic-proposed fix must be applied before exit.
A REMOVE fix never blocks, whatever its severity. Acceptance is
about whether the unit may leave the loop, and a removal that the patch
screening refused -- because it would empty a subject, or exceed the
delete cap -- is precisely a removal that should not hold the unit back.
The screening decides what may be deleted; this decides what is worth
another pass, and a deletion is never the thing worth insisting on.
Source code in ontocast/tool/facts_validation/acceptance.py
MaterialDefect
¶
Bases: BaseModel
One reason a rendered unit is not acceptable as it stands.
Source code in ontocast/tool/facts_validation/acceptance.py
Functions:¶
accept_reason(defects)
¶
A short, aggregatable label for why the unit was accepted or not.
Source code in ontocast/tool/facts_validation/acceptance.py
material_defects(findings, fixes, policy=None)
¶
Every reason the unit is not acceptable, deterministic evidence first.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
findings
|
Sequence[UnitFinding]
|
Deterministic findings collected against the current graph. |
required |
fixes
|
Sequence[TripleFix]
|
Fixes the LLM critic proposed, if it ran. Empty is normal --
with |
required |
policy
|
FactsAcceptancePolicy | None
|
The deployment's cut. |
None
|
Returns:
| Type | Description |
|---|---|
list[MaterialDefect]
|
Material defects; empty means accept. The list is returned rather than |
list[MaterialDefect]
|
a bool so the caller can record why a unit was rejected, which the |
list[MaterialDefect]
|
score gate never made recordable. |