Methodology Committee

Who approves Philidor methodology versions, how reviewer attestations are signed and verified, and how corrections are published.

The methodology committee owns the published risk methodology: the dimensions, the weights, the tier boundaries, and every version bump. This page exists so that a reader who sees a reviewer slug in the API can find out what that role is accountable for.

Roles

The public roster is served by GET /v1/reviewers. Each entry is a role, and each role is accountable for a defined scope rather than for a personal opinion.

Role slug (`role` on `/v1/reviewers`)	Scope
`methodology_lead`	Owns the per-basket methodology, eligibility policy, and every methodology version bump.
`asset_specialist`	Reviews tokenized fund disclosures, wrapper structure, custody, and redemption terms for assets in the RWA universe.
`protocol_specialist`	Reviews protocol audits, governance changes, incident postmortems, and per-vault classification.
`risk_analyst`	Reviews scoring inputs and monitors score movement against the published method.
`committee`	Group attestation used for records created before per-role attribution shipped. Retained for continuity.

Roles are published rather than individual biographies. Accountability rests on the signed record described below, on the published method, and on the correction process, not on a claim about who we are.

What a signed attestation covers

A reviewer attestation is an Ed25519 signature over the canonical form of one specific version of one classification. It is not a blanket endorsement of the asset, and it is not automatically carried forward to later versions.

That has a consequence worth stating plainly: when a classification is revised, the new version is not covered by the previous signature. It carries a signature only once it has been reviewed again. Automated data refreshes are machine publications and are never signed with a reviewer key.

The public API therefore distinguishes between a record that is signed for its current version and one that is awaiting re-review. Read the attestation state from the asset record rather than assuming that a reviewed asset is a signed one.

Current state of signing

Being precise about this matters more than sounding assured.

The signing scheme above is implemented, and the attestation ledger is append-only, so a superseded classification keeps whatever record was written against it. What is not true today is that every current classification carries a valid reviewer signature. Automated refreshes roll a classification to a new version, and that new version is not covered by a signature issued against the previous one.

Two consequences follow, and neither is hidden:

attestation_count on the public roster counts signed human attestations only. A count of zero means exactly that, rather than an error.
A reviewed asset is not necessarily a signed asset. Read the attestation state from the asset record rather than inferring it from review_status.

Public verification of an individual attestation, including the reviewer public key needed to check a signature, is not yet exposed on the API. Until it is, treat the reviewer of record as attribution rather than as proof, and ask us if you need the underlying record for an audit file.

Methodology versions and corrections

Every methodology version is published at GET /v1/methodology with its changelog. The version that produced a given score is pinned on the record itself, so read the version from the asset rather than assuming the newest one applied when the score was written.

Where a published changelog entry later proves inaccurate, we publish a dated correction against that version rather than editing the original text. The original wording stays as written, and the correction records what was wrong and when we said so.

Raising a concern

To challenge a published classification or a methodology decision, write to contact@philidor.io. Corrections are published, not applied quietly.