RTL-STD-001 · Governance

How the standard changes

Who decides, how a threshold moves, how a check enters or leaves, how versions are numbered — written as an operating document, with unfilled seats marked as such.

What this page governs

RTL-STD-001, the Sphinx Standard, is a published specification of 56 checks for reviewing the appraisal behind a residential transition loan. This page records how the standard changes: who can propose a change, how a threshold moves, how a check enters or leaves, how versions are numbered, and who reviews every change before it publishes. It is written as an operating document. Where a role is not yet filled, it says so.

Current state: version 1.0, 0 of 56 thresholds calibrated, 0 contributing lenders. The canonical figures live on the status page; nothing here states a number that page does not also state.

Roles

Maintainer

Sphinx maintains the standard: it holds the pen on check definitions, runs the calibration studies under the published protocol, and publishes every version. The maintainer cannot move a threshold without outcome evidence, and cannot publish a change the contributor committee has held.

Contributor committee — three seats, named by role

Seat	Who fills it	What the seat protects	Status
Originator	A credit or collateral lead at a contributing RTL lender, nominated by the founding contributors.	That the checks reflect how these loans are actually underwritten, and that a change does not quietly shift work onto the lender.	Open
Capital markets	An analyst or diligence lead at a whole-loan buyer, warehouse lender, or rating agency.	That a finding stays intelligible and reproducible to a reader with no relationship to Sphinx, years after it was produced.	Open
Valuation practitioner	A certified residential or certified general appraiser with review experience.	That the standard stays on the analytical-review side of the line: not an appraisal, not a USPAP Standard 3 review, never a channel to an appraiser.	Open

All three seats are unfilled at publication. Until they are filled, every change publishes with its committee review recorded as not yet constituted, so a reader can see which versions had independent review and which did not.

The committee sees pooled statistics only after they clear the aggregation thresholds below. It never sees a contributor's files, and never sees anything that identifies a lender, a borrower, or a property. It does not set pricing, credit policy, advance rates, or any commercial term for any participant, and does not discuss them. It does not see, produce, or circulate any appraiser-level list, score, or ranking.

How a threshold changes

Only on outcome evidence. A threshold moves when a calibration study, run under the pre-registered validation protocol, supports the move. Intuition, a customer request, or convenience do not move a threshold.
Provenance changes with it. A moved threshold is relabelled Calibrated with its sample size published beside the number. The sample size is never omitted.
Aggregation thresholds first. No pooled statistic is used to set or publish a threshold until its cell clears a minimum observation count from a minimum number of distinct contributors. The minimums publish with the first calibrated version. Their purpose is to make it impossible to reverse-engineer any one lender's book from a published number.
Market by market. Where the evidence supports different thresholds in different submarkets, the standard publishes the rule for deriving the local threshold rather than a single national figure.
Sphinx-original methods stay in the implementation. The specification states what each check tests and when it fires. For checks original to Sphinx, the parameters that implement the firing condition belong to the reference implementation, not the specification. A calibrated change to them is recorded as parameters refitted with the sample size, without publishing the parameters themselves.

How a check is added

A proposal states what the check tests, when it fires, what it outputs (a flag, an interval contribution, or a dollar effect on value), and its provenance: an existing industry practice, or original.
The proposal is open for comment for at least 30 days at standard@sphinx.credit. Every substantive comment receives a written response, published with the change.
The check enters the standard as Industry Baseline or Sphinx-Original, uncalibrated, with a stable ID that is never reused.
Its predictive value is tested under the validation protocol at the next study of sufficient size. Until then it carries no calibration claim.

How a check is removed

A check that fails to earn its place comes out. The validation protocol fixes the rule in advance: a check that shows no predictive relationship to realised outcomes at the expanded sample is flagged for review, and if it still shows nothing at the following study it is removed, with a dated entry stating the result. Removed IDs are retired, never reassigned. Findings produced against a version that included the check remain valid against that version, which is why every finding records its standard version by value.

This applies to every check, including the checks original to Sphinx and the check the company was built around. The protocol's pre-written conclusion for that case publishes with the protocol.

Versioning

v1.0 is the initial publication. There is no earlier version anyone relied on, so there is no history before it.
Minor version (v1.1, v1.2 …): a threshold refitted on outcome evidence, a firing condition of an existing check changed, or a wording clarification that does not change what a check tests.
Major version (v2.0): a check added, removed, or redefined; a family added; an output type changed.
Every change is a dated changelog entry stating what moved, why, the evidence behind it (study and sample size), and the committee's review status. The changelog begins at publication and is never rewritten.
Prior versions stay published. A finding cites the version it was produced against and the threshold values actually used, so a reader in a later year can reconstruct it without asking anyone.

What no version of the standard will contain

An appraiser ranking, list, roster, or comparative score, in any output, export, or API response, including internal tools. Appraiser-level effects, where estimated, adjust a value; they never describe a person.
Any output addressed to an appraiser, or any finding used as a basis for requesting a revision to a report. To clear guidance in a finding may reference the borrower's budget, scope, or the loan structure; it never references an adjustment, a comparable selection, or a value conclusion the appraiser would have to revise.
An advance rate, LTV, LTARV, or any credit-policy threshold.
A forward projection of value. Forward drift widens an interval; it never moves a point estimate.
A calibration claim without a sample size beside it.

Comment and dispute

Anyone may comment on any check at any time: write to standard@sphinx.credit with the check ID. Comments on a proposed change publish with the change. A contributor who believes a published threshold misreads their market can ask for the cell to be re-examined; the re-examination follows the same protocol and publishes whether or not it changes the number.

Home The standard Governance Methodology note Validation protocol Status Sample finding FAQ Glossary Team About

RTL-STD-001 v1.0 · published · this page last updated 2 September 2026 · status

The Sphinx standard describes analytical review of an appraisal report. It is not an appraisal, not a valuation, and not a review appraisal under USPAP Standard 3. Outputs are internal analytical inputs for credit decisioning. They are not communicated to appraisers and are not a basis for requesting revision to any report.