Methodology & governance
Publish the hash, not just the prose.
A methodology registry that rejects a changed rulebook hash, revisions that require a named approver and a written rationale, and a retained oversight log.
What this page is
This describes governance design implemented in the index engine. It is not an attestation, an audit opinion, or a certification. Current status: customer-serving benchmark publication remains gated, and greencio does not currently claim IOSCO compliance.
Controls
What the system will not let you do
The distinction that matters to a reviewer is whether a control is a policy someone follows or a path the system will not take. These are the second kind.
Hash-registered methodology versions
A methodology version is registered with the hash of its rulebook. Attempting to re-register the same version with a different hash is rejected outright.
rulebook_hash CHECK constraint + registry collision guard
Revisions require an approver
A change records the version it moved from, the version it moved to, the effective date, the named approver, and the rationale. A revision missing any of these cannot be recorded.
versionOld · versionNew · effectiveDate · approver · rationale
Retained oversight actions
Oversight decisions are recorded against the index they concern and are listable, so the review history is a queryable record, not an inbox.
Oversight action log, filterable by index
Per-settlement input hash
Each settlement hashes its input set, tying a published value to exactly the quotes that produced it and making silent restatement detectable.
SHA-256 over the settlement input set
Rejection reasons are typed
Quotes are not simply dropped. Each rejection carries a typed reason, so the shape of what was excluded can be analysed.
Enumerated rejection reason per rejected quote
Provisional excluded by default
The permissive path requires a deliberate override. The default behaviour for an uncertain settlement is to withhold it.
band > 15% → excluded unless explicitly included
Change lifecycle
How a methodology change happens
- 1
Propose
A methodology change is drafted against the current version, with the rationale stated before the change is made, not reconstructed afterwards.
rationale required
- 2
Register
The new version is registered with its rulebook hash. If the version already exists under a different hash, registration fails.
hash collision → reject
- 3
Approve
The revision is recorded with a named approver and an effective date, so approval leaves a trace that can be produced on request.
approver + effectiveDate required
- 4
Apply forward
Settlements carry the methodology version they were produced under, so a historical value is interpretable against the rules in force at the time.
methodologyVersion stamped per settlement
Questions
For compliance reviewers
Is this an accredited or audited benchmark?
No. This page describes how we govern the index, not an external attestation. Current status: customer-serving benchmark publication remains gated, and greencio does not currently claim IOSCO compliance. Nothing here should be read as an assurance opinion.
Who can change the methodology?
A change requires a registered version with its rulebook hash, plus a revision record naming the approver, the effective date, and the rationale. The controls cause an unrecorded change to fail.
What stops a number being restated after the fact?
Each settlement hashes the input set that produced it and carries the methodology version in force at the time. A restatement that does not match its recorded inputs is detectable.
Can the index be used as a settlement reference in a contract?
Not today. Customer-serving benchmark publication remains gated, and the framing, governance, and counsel review that a contractual reference requires are not complete. We will not encourage a use the current status does not support.
What gates publicationPut the governance design in front of your reviewer.
We will walk a compliance or diligence reviewer through the registry, the revision requirements, and the settlement lineage.