Skip to content

Rulvar API reference


Rulvar API reference / @rulvar/core / OrchestrateClaimConsistencyMeta

Interface: OrchestrateClaimConsistencyMeta

Defined in: packages/core/src/orchestrator/orchestrate.ts:1712

What the claim-consistency pass looked at, beside its findings. Rides the acceptance envelope as claimConsistencyMeta whenever the pass is configured, exactly like contradictionsMeta: [] plus this meta says "the fold paired pairs sentences and the judge cleared them", while an absent pair of fields says nothing looked. judgeInvoked false records that no pair existed to judge, and judgeFailed names a judge invocation that did not settle ok, in which case claimContradictions is absent: nothing was judged, and an empty list would claim the pool agreed.

Properties

PropertyTypeDescriptionDefined in
coverageClaimCoverageGradeThe one field a consumer reads INSTEAD of inferring semantic health from an empty findings array (RV1702): claimCoverageOf over this meta, so completion: 'complete' plus contradictions: [] can never again read as "fully verified" when the judge saw 40 of 144 citing sentences.packages/core/src/orchestrator/orchestrate.ts:1811
coverageTarget?numberPresent when coverageTarget was declared (RV2903): the share the pass sized itself for, echoed so a persisted outcome says WHAT the coverage was held against, not only what it reached.packages/core/src/orchestrator/orchestrate.ts:1732
coverageTargetDeclared?truePresent when the pass ran under an effective coverage target (RV4404): declared coverageTarget, or the target 1 a declared semanticAcceptance derives. A truncation then grades 'coverage-capped', naming the ceiling as the cause.packages/core/src/orchestrator/orchestrate.ts:1739
coveredCitingSentencesnumberCiting sentences with at least one judged pair (RV1603): the honest coverage numerator against draftCitingSentences, so [] findings over 40 of 144 sentences can never read as "fully verified".packages/core/src/orchestrator/orchestrate.ts:1726
criticalUncovered?string[]Present when critical was declared: the critical draft anchors with no judged pair (capped at MAX_CRITICAL_UNCOVERED); [] means every declared claim the draft cited was judged.packages/core/src/orchestrator/orchestrate.ts:1745
criticalUncoveredTotal?numberThe uncapped count behind criticalUncovered; present with it.packages/core/src/orchestrator/orchestrate.ts:1747
draftCitingSentencesnumberDraft sentences carrying at least one parsable anchor.packages/core/src/orchestrator/orchestrate.ts:1716
findings?numberHow many judged contradictions the pass FOUND on the judged document, present exactly when the judge settled ok (RV3304): 0 is a clean verdict, a positive count is a disagreement that stayed wherever the posture did not stop the run. The findings themselves ride claimContradictions beside this meta on the acceptance envelope, and since RV3601 the engine lifts them onto RunOutcome, the journaled settle and run:end beside the meta, from the envelope or the typed error data alike: the 2026-08-12 comparison run settled ok/complete over a retained finding no terminal surface could count (this count is that fix, RV3304), then the 2026-08-13 run failed typed with the findings buried in error data while the outcome's top level read null. Only the compact terminal envelope still carries the meta alone, this count standing in for the details.packages/core/src/orchestrator/orchestrate.ts:1803
firstPassCoverage?ClaimCoverageGradeThe coverage grade of the FIRST pass (RV4202), present exactly when a coverage-armed round ran (passes exceeds 1 under coverageRepair): the meta above always describes the LAST pass, so without this field a 'full' grade earned through the round would be indistinguishable from a clean first verdict.packages/core/src/orchestrator/orchestrate.ts:1865
firstPassFindings?numberThe findings count of the FIRST pass of this stage (RV3904), present exactly when passes exceeds 1: what the repair round consumed, so "zero findings after one round over one first-pass finding" reads off the envelope instead of the journal.packages/core/src/orchestrator/orchestrate.ts:1857
judgeDeclined?truePresent when the judge invocation was refused ADMISSION and never dispatched (RV2106): the ninth parity run's judge estimate did not fit the orchestrator account's working room past the held synthesis reserve, and the bare refusal killed a run whose fan-out and draft were already complete. The declined pass degrades like a failed judge (the meta names it, the journaled decision carries the arithmetic, only the armed 'fail' posture stops the run) and the synthesis its reserve was holding money for still dispatches.packages/core/src/orchestrator/orchestrate.ts:1786
judgedHashstringsha256 over the canonical document this verdict read (RV2509). Compare it against the envelope's draftToFinal.finalHash: equal means the judged document IS the one that shipped, unequal means the synthesis rewrote what the judge cleared.packages/core/src/orchestrator/orchestrate.ts:1826
judgedJcsSha256?stringThe precise twin of judgedHash (RV4604): the same hex under a name that states the recipe, sha256 over the JCS canonical document (a string document hashes as its JSON encoding, so a file export's own sha DIFFERS; verifyCandidateBytes is the audit predicate). The seventh comparison experiment's provenance script rediscovered the recipe by trial because the bare name said nothing. Absent on metas recorded before the field.packages/core/src/orchestrator/orchestrate.ts:1836
judgedStage"draft" | "final"WHICH document this verdict describes (RV2509): 'draft' for the pre-synthesis pass, 'final' for a pass over the artifact the run settles on. Always present since RV2509, so a coverage grade can never be read as a claim about the shipped document when it was rendered over the draft the synthesis replaced.packages/core/src/orchestrator/orchestrate.ts:1819
judgeFailed?truePresent when the judge invocation did not settle ok.packages/core/src/orchestrator/orchestrate.ts:1775
judgeInvokedbooleanTrue when the judge invocation was dispatched.packages/core/src/orchestrator/orchestrate.ts:1773
lowCoverage?{ coverageFloor?: number; coverageRatio: number; runFactFloor?: number; runFactRatio?: number; }Present when a declared coverage floor was not met under onLowCoverage: 'report' (RV1809): each ratio beside its floor, machine-readable, so "complete but under-verified by the declared floor" is a field, not an external computation. Under 'fail' the run fails typed instead and the meta stamps this block on the way out.packages/core/src/orchestrator/orchestrate.ts:1766
lowCoverage.coverageFloor?number-packages/core/src/orchestrator/orchestrate.ts:1768
lowCoverage.coverageRationumber-packages/core/src/orchestrator/orchestrate.ts:1767
lowCoverage.runFactFloor?number-packages/core/src/orchestrator/orchestrate.ts:1770
lowCoverage.runFactRatio?number-packages/core/src/orchestrator/orchestrate.ts:1769
pairsnumberPairs the fold produced (and the judge ruled on, when invoked).packages/core/src/orchestrator/orchestrate.ts:1718
passes?numberHow many judge passes this stage's verdict lineage ran (RV3904, the fourth comparison experiment): present exactly when the bounded claim repair round is armed (onFound: 'repair'), so a consumer reading findings: 0 can tell a clean FIRST verdict (passes: 1) from a verdict earned through a repair (passes: 2, the meta above always describing the LAST pass). The experiment's terminal read findings 0 over a lineage whose first pass had caught a real contradiction, and only the journal could say so. Absent on journals and configs from before the field, and absent when no repair round is armed: NOT RECORDED, never a claim of a single pass.packages/core/src/orchestrator/orchestrate.ts:1850
poolChildrennumberHow many accepted children the fold read.packages/core/src/orchestrator/orchestrate.ts:1714
runFactCandidates?numberPresent under runFacts (RV1809): the UNCAPPED count of matched run-claim sentences, so the run-fact coverage ratio is computable from the meta alone, live or from a persisted outcome.packages/core/src/orchestrator/orchestrate.ts:1757
runFactPairs?numberPresent under runFacts: run-claim pairs judged against the fact sheet.packages/core/src/orchestrator/orchestrate.ts:1749
runFactPairsTruncated?truePresent under runFacts when more run claims matched than the bound.packages/core/src/orchestrator/orchestrate.ts:1751
semanticRepairRounds?numberBounded semantic repair rounds actually dispatched at this stage (RV3904); today 0 or 1, the evidence-grade precedent. Distinct from the finish validation's mechanical repairsUsed, which counts model repair turns INSIDE one invocation and keeps its byte contract untouched.packages/core/src/orchestrator/orchestrate.ts:1873
truncatedbooleanTrue when more pairs existed than max allowed to judge.packages/core/src/orchestrator/orchestrate.ts:1720