Methodology governance
This page describes implemented mapping and semantic-review controls, then separates them from the broader governance model still to be built.
A mapping relates venue contracts or outcomes to a canonical event. Suggested relationships can enter review, and the current review endpoint records a VERIFIED or REJECTED verdict, reviewer, time, notes, and risk treatment. This is a narrow implemented review path, not a complete institutional approval workflow.
SUGGESTED and REVIEW_REQUIRED relationships can be reviewed into VERIFIED or REJECTED. A rejected relationship cannot receive risk credit. Reviewed VERIFIED, REJECTED, and RETIRED rows are immutable. A later change requires retiring the old row and creating a new suggestion; the revision and retirement workflow is not yet available as a complete customer-facing process.
A fuller model would explicitly record proposal, independent review, approval or rejection, revision, retirement, effective time, evidence, and user notice. Those stages are a target model. The current code does not implement that complete lifecycle or a formal committee process.
A relationship status of VERIFIED maps to the displayed VERIFIED state. It identifies a reviewed semantic relationship; it does not guarantee that source terms stay unchanged.
The underlying REVIEW_REQUIRED workflow status maps to PARTIAL in the public display. It means review is still required and possible semantic differences remain unresolved; it is not a final partial approval.
REJECTED and RETIRED relationships map to NOT_EQUIVALENT in the public display. A rejected relationship must carry NO_CREDIT.
SUGGESTED or missing relationships map to UNREVIEWED. Similarity and automated suggestions are not approval.
The workstation can roll multiple contract relationship states up conservatively: one unresolved relevant relationship may keep the event-level result at UNREVIEWED. A relationship’s workflow status and the displayed semantic state are related but distinct vocabularies.
The collector stores append-only contract rule/metadata hash versions and emits RULES_CHANGED when a new hash is observed; lifecycle and source-health signals are separate. This detects source changes, not their legal meaning. A new source rule does not automatically rewrite a mapping or assert that a reviewed relationship remains valid. Mapping-version rows pin relationship IDs for reproducible risk runs. They do not archive an external authority’s complete methodology, every prior customer-facing record, or all source terms for every venue.
Report a suspected data or methodology error through the published contact channels. The public corrections page records disclosed incidents and their remediation where applicable. The current system does not promise automatic customer notification for every change, nor does this page claim universal retention of every historical display state. Mapping versions and append-only source-rule versions preserve specific versioned records where implemented.
A mapping review can retain reviewer identity and time, verdict, notes in stored review evidence, risk treatment, and linked relationship/version identifiers. Source-rule versions retain the observed hashes and raw source payload captured by the collector. The available evidence depends on the workflow and source; it is not legal certification or a claim that every decision has a full external evidence package.
Commercial considerations must not silently alter semantic classifications or methodology states.
For an infrastructure discussion: Discuss an Infrastructure Partnership
