How the method is versioned

If the rules behind a score can move without anyone saying so, this year's score cannot be compared with last year's, and a report issued under it means very little. The Theos Method is therefore versioned the way a public API is versioned: an explicit identifier, a documented policy for what may change within it, notice before a change lands, and a permanent record of every published revision. The current version is theos-method-v1.0, published 2026-07-27 at /methodology, superseding theos-method-v0.1 (published 2026-07-25).

#The version identifier

The method carries a semantic version of its own, independent of any product or platform release number. Platform releases happen often. The method changes rarely and deliberately.

theos-method-v<MAJOR>.<MINOR>[.<PATCH>]

theos-method-v0.1     superseded — retained for reports issued under it
theos-method-v1.0     current    — the published specification
theos-method-v1.0.1   patch      — wording only; no score can move
theos-method-v1.1     minor      — additive; some scores may move
theos-method-v2.0     major      — breaking; scores are not comparable

The rule is short to state and it is the whole contract: a patch cannot change any score, a minor may change some scores, a major may change every score. Anything that would move a number is at minimum a minor version, even when it looks like a clarification from the inside.

#Breaking versus additive change

The distinction customers care about is not major against minor in the abstract. It is whether their existing numbers still mean what they meant. This table is the operative one.

A worked example of the boundary. Adding a detector that recognises an algorithm variant we previously missed is additive: no existing asset changes its score, but the estate may contain more assets than it did, so the count and the aggregate can move. Changing the weight of the Primitive Fragility dimension from 30 to 25 is breaking: nothing new is discovered and every score in the estate shifts. The first is a minor version. The second is a major version, and it is not permitted to arrive without notice.

#Why a score without a version is not a score

Every figure we issue is stamped with the method version that produced it. This is not decoration. A score of 68 under one set of scoring rules and 68 under another are two different statements that happen to share a numeral, and treating them as the same value is the most common way vendor metrics quietly stop meaning anything.

So the version travels with the number everywhere: in the report header, in every export, in the API payload, and in the Posture Attestation a third party can look up through /attest. If you quote one of our figures in a board pack, a regulatory filing or a supplier questionnaire, quote the version with it. The citation formats on /methodology already include it.

#Re-scoring an old estate under a new version

Old reports are never retroactively rewritten. A report issued under theos-method-v0.1 stays pinned to theos-method-v0.1 for as long as it exists, and its numbers are frozen. When you want a comparable figure under a newer version, we re-score rather than edit.

1. 01The original artefact chain is retained under its own version stamp. It is not modified, and the original score remains retrievable.
2. 02The retained inventory is replayed through the newer version's rules. Where the newer version needs an input the older collection did not capture, that gap is reported rather than estimated.
3. 03A second, clearly labelled result is issued under the new version, alongside a diff explaining which factors moved and why.
4. 04Both results stay on the record. The customer chooses which to cite, and may cite both.

A replay is not the same as a fresh assessment. It re-applies new rules to old evidence, so it cannot discover anything the original collection did not see. Where a new version adds a detector, only a fresh collection will find what that detector was built for. We say which of the two you are getting before the work starts. Commercial terms for a re-score outside an active engagement: [PLACEHOLDER: re-score pricing and inclusion terms].

#How long a superseded version stays useful

Superseded versions are not deleted. The specification text for every version we have published stays readable indefinitely, because a report that cites a version is worthless if the cited text disappears. What does expire is the claim that a superseded version is a sound basis for new comparisons.

Readable

Indefinitely. Every published version stays available at a stable URL

Valid for interpreting an existing report

Indefinitely. That report's numbers never move

Valid for new comparisons

[PLACEHOLDER: comparison-validity window for superseded minor versions]

Default for new assessments

The current version only. Older versions are not offered for new work

Deprecation notice

[PLACEHOLDER: deprecation notice period before a version stops being supported for re-scores]

Deprecating a version means we stop performing re-scores against it, not that we stop publishing it. The distinction matters to auditors, who need the text for far longer than they need the service.

#The Evidence Ledger

The Evidence Ledger is an append-only record of the method's history. Each entry describes one published event — a new method version, a patch, a deprecation notice — and carries a SHA-256 digest of the exact content published at that moment, plus the digest of the entry before it. Entries are only ever appended. Nothing is edited in place.

{
  "entry": "[PLACEHOLDER: sequence number]",
  "type": "method_version",
  "version": "theos-method-v1.0",
  "published_at": "2026-07-27",
  "content_sha256": "[PLACEHOLDER: digest of the published specification]",
  "prev_entry_sha256": "[PLACEHOLDER: digest of the preceding entry]",
  "ledger_url": "[PLACEHOLDER: public Evidence Ledger URL]"
}

Because each entry commits to its predecessor, altering an old entry invalidates every digest after it. That gives the ledger one useful property. Hand somebody a report, a version identifier and a ledger entry, and they can recompute the digest of the published specification and confirm it matches. If it matches, the text you were scored against is the text still on the record. If it does not, something changed and you should ask us why.

The ledger is a machine-readable spine. The human-readable history — what changed, why, and what it means for your numbers — is written up in /signal-log, and the wider control and assurance picture sits at /assurance.