Assure and Govern a Financial-KG Benchmark

Build a traceable AssuranceAndGovernancePackageSet with two governed chains:

assurance check → assurance run → assurance evidence → finding → assurance conclusion

governed asset → health record/trigger → change record → release → compatibility/challenge/retirement

Preserve the layer boundary

• Assure the evaluation, not the graph: determine whether an evaluation process, evidence package, or published result is trustworthy. Never reinterpret the graph-quality construct, replace a quality requirement, change a graph-quality metric, or issue a graph pass/fail decision.
• Reference exact external artifacts: admit upstream specifications, runs, evidence packages, judgments, disclosures, graph snapshots, reference assets, tools, models, prompts, and approvals only by exact identity, version, hash, and lifecycle state. Never copy and mutate their semantics.
• Separate evidence from conclusion: an observation becomes AssuranceEvidence; a supported problem becomes an AssuranceFinding; only a frozen aggregation rule may produce an AssuranceConclusion.
• Keep trust states distinct: assured, assured_with_limitations, not_assured, insufficient_evidence, and invalid_assurance_run describe evaluation trustworthiness, not graph quality.
• Govern the benchmark, not the evaluated graph product: manage benchmark test data, gold standards, ontologies, reference data, rules, specifications, workloads, code, environments, models, prompts, documentation, and releases. Do not manage the evaluated graph's product lifecycle unless separately authorized.
• No automatic mutation: a health record, challenge, or finding may raise a ChangeTrigger; a trigger cannot edit an asset, create a release, withdraw a result, or retire anything without a governed ChangeRecord, evidence, review, and approval.
• Immutable history: never edit an active or historical release in place. Corrections, re-tests, re-judgments, re-disclosures, lifecycle-state transitions, withdrawals, supersession, and retirement require a new package-envelope version plus an explicit record or LifecycleStateEvent with lineage.
• Comparability is explicit: never infer comparability from a shared benchmark name or version family. Record construct, population, reference, metric, test-data, sampling, and execution compatibility; require a bridge or trend break when needed.
• Challenges remain independent: preserve admissibility, reviewer independence, conflicts, evidence, decision rationale, corrective action, and appeal lineage. A case decision never silently overwrites the challenged record.