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.
FactsAcceptancePolicy
¶
Bases: BaseModel
Which defects block a rendered unit from leaving the loop.
Attributes:
| Name | Type | Description |
|---|---|---|
blocking_finding_kinds |
frozenset[FactsUnitFindingKind] | 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
blocks_finding(finding)
¶
True when this deterministic finding must be repaired before exit.
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. The repair prompt
it would be rendered into states that a finding is never resolved by
deleting the statement, so a mandatory REMOVE would contradict the block
it sits in -- the same shape of contradiction that
shacl_catalog_contradictions exists to catch, and one that has
already caused repair renders to delete valid values wholesale.
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
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[FactsUnitFinding]
|
Deterministic findings collected against the current graph. |
required |
fixes
|
Sequence[TripleFix]
|
Fixes the LLM critic proposed, if it ran. Empty is normal --
at |
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. |