The Theos Method, in outline

The Theos Method is the published procedure AutoPQC follows to turn an enterprise estate into a ranked migration plan. It runs in eight stages. Each stage produces a named artefact, and each artefact is the input to the next, so any finding can be walked backwards to the cryptographic fact that caused it. This article is the readable outline. The formal specification — the five weighted factors, the exact rules, the tier boundaries and the reference list — is published at /methodology under the version identifier theos-method-v1.0.

#Why the method is published at all

A risk score is a claim about somebody else's infrastructure. If the reasoning behind that claim is private, the customer has no way to argue with it, an auditor has no way to test it, and we have no way to prove we did not change our mind between two engagements. Publishing removes all three problems at once, and it costs us nothing we want to keep.

Four things follow from publication, and they are the reason we treat the method as a product surface rather than internal documentation.

• A finding can be contested. An engineer who disagrees with a score can point at the specific factor and rule that produced it, not at a black box.
• An auditor can cite a revision. Workpapers reference theos-method-v1.0 rather than a vendor name, and the cited text does not move underneath them.
• Two runs can be compared. The same estate under the same method version produces the same score. Any difference is a change in the estate, not a change in our mood.
• Errors get found. A method held in public gets read by people who are paid to break things. We would rather they find a weak rule than a customer find it in production.

Corrections are welcome and we publish versioned responses to them. There is no bug-bounty scheme for the method itself; write to us through /contact and we will tell you whether we agree and what we intend to change.

#The eight stages, in order

Nothing here is exotic. The value is in the ordering, and in refusing to skip a stage because the customer is in a hurry.

1. 1

   1 — Scope agreement

   Before any collector runs, we and the customer write down which systems, networks, repositories and accounts are in scope, who authorises access, and what is explicitly excluded. Scope is a signed document, not a conversation. Everything downstream inherits its boundaries, which is why an estate score is only meaningful alongside the scope it was computed over.

2. 2

   2 — Collection

   Read-only collectors gather evidence from the agreed sources: configuration, certificate stores, code and dependency manifests, key-management metadata, protocol negotiation records. We collect facts about cryptography, not the material it protects. See How discovery finds cryptography for the mechanics and What discovery will not do for the boundaries.

3. 3

   3 — Normalisation

   Raw observations arrive in a dozen shapes. Normalisation resolves them into one asset model with stable identifiers, deduplicates the same key seen through three collectors, and records provenance for every field. This is the least glamorous stage and the one that decides whether the count at the end is defensible.

4. 4

   4 — Classification

   Each normalised asset is assigned an algorithm family, a usage category and a confidence value. The classifier reports 95.2% accuracy and 0.94 macro-F1 on our labelled evaluation set. Low-confidence assets are routed to review rather than scored silently; see Accuracy, false positives, and how we report error.

5. 5

   5 — Scoring

   Every classified asset is scored 0–100 as the weighted mean of five dimensions: Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap. The rules are deterministic. The estate-level figure is the criticality-weighted aggregate of the per-asset scores.

6. 6

   6 — Prioritisation

   Scores rank assets; prioritisation turns that ranking into an order of work. Assets are grouped into the four risk tiers, then sorted within tier by the factors that respond fastest to effort. A high score with a cheap fix outranks a marginally higher score that needs a vendor release.

7. 7

   7 — Sequencing

   Priority ignores dependencies; sequencing does not. A certificate authority has to move before the endpoints that chain to it. Sequencing lays the prioritised work onto a dependency graph and produces a migration order with hybrid stages and rollback points, covered in Sequencing a migration.

8. 8

   8 — Verification

   After a change ships, the same collectors re-run against the same scope and the score is recomputed under the same method version. Verification is what separates a migration plan from a migration. It also produces the before-and-after performance evidence described in Proving the performance impact.

#What each stage leaves behind

Each stage emits an artefact that can be exported and handed to somebody who was not in the room. This is the chain an auditor follows, and it is the reason a report is longer than a number.

The cryptographic bill of materials is assembled from the normalisation and classification artefacts rather than being a separate output; see Cryptographic bills of material. What an external reviewer typically asks for is described in What to hand an auditor.

#Where a person decides, not the model

AutoPQC is heavily automated and deliberately not autonomous. The model classifies and the rules score, but several decisions are reserved for a named human being because they are judgements about the business rather than facts about cryptography.

• Scope. A person decides what is in and out, and signs it. No collector expands its own reach.
• Data longevity. How long a record must stay confidential is a legal and commercial answer. The customer supplies it; we do not infer it from file paths.
• Operational criticality. Which systems sit on the revenue path or inside regulatory scope is the customer's call, reviewed with our engineer.
• Low-confidence findings. Anything the classifier is unsure about goes to a reviewer before it reaches a report. It is never quietly assigned to the most likely class.
• Accepting a risk. A decision to leave an Acute asset in place is recorded with a named owner and a date. We do not close it on the customer's behalf.
• Publishing a method change. Changes to the scoring rules are approved and versioned by people, never learned automatically from production data.

#What the score is, and what it is not

The output of the method is a prioritisation instrument. It answers the question of what to migrate first given finite engineers and a fixed window. It does not answer whether an attack is under way, and it is not a probability.

Range

0–100 per asset; the estate figure is the criticality-weighted aggregate

Direction

Higher means more exposure. The pilot estate's 75/100 sits inside the Elevated tier, ten points above its floor and ten below Acute

Tiers

Acute 85–100 · Elevated 65–84 · Watch 40–64 · Contained 0–39

Determinism

Same estate, same scope, same method version, same score

Not

Not a breach probability, not a compliance verdict, not a penetration test result

Two estates with the same score are not equally at risk in any absolute sense. They are equally urgent relative to the same scoring rules, which is a narrower and more useful claim. How the exposure score is built and What the risk tiers mean go further into this, and Claims we refuse to make lists the assertions we will not attach to a number.

#Where to read the formal treatment

This page is the outline. The specification is the authority, and where the two disagree the specification wins.

• /methodology — the canonical specification: factor table with weights, scoring rules, tier mapping, validation figures, citation formats and references.
• How the method is versioned — the change policy, and why a score must always travel with the version identifier that produced it.
• Reproducing our numbers — what each published figure measures and what would make it not transfer to your estate.
• Lexicon — the shared vocabulary, so that terms like asset, exposure and agility mean one thing across every page.