Why a specific asset was flagged

A score you cannot interrogate is a score you cannot act on. Every finding AutoPQC raises carries a record that runs from the raw detector observation to the tier, with each step named and each input attributed. This page describes that record, shows one, explains how to contest a finding you believe is wrong, and sets out how an override is stored so the score stays auditable afterwards.

#What a finding record contains

A finding is the unit of explanation. It is not a log line and it is not a score; it is the complete justification for one assertion about one asset, and it is designed to be read by an engineer, a risk owner and an auditor without translation.

Finding identifier

Stable for the life of the finding. Survives re-scoring and appears on every export.

Asset identifier

Points at the inventory entry, not at a host. See What counts as an asset.

Method version

The version of The Theos Method under which the score was computed. Never rewritten.

Detector and observation

Which detector fired, what it saw, and a pointer to the stored evidence for that observation.

Primitive and parameters

The algorithm, mode, key size or curve, and the construction it appears in.

Five dimension sub-scores

Each with its value, its provenance class, and the rubric anchor it was matched to.

Computed and final score

The weighted mean before rounding, after rounding, and after the fragility floor if it bound.

Tier

One of Acute, Elevated, Watch or Contained.

Owner

The accountable owner as declared during intake.

First seen and last confirmed

Two dates. A finding that has not been re-confirmed is shown as stale rather than silently carried forward.

Override history

Every override ever applied, with author, reason and timestamp. Append-only.

Evidence digest

A hash over the record, written to the Evidence Ledger so later tampering is detectable.

#The evidence chain, end to end

Six steps separate a detector observation from a tier. Each one is recorded, and each one can be the subject of a challenge, which is the reason we keep them distinct rather than collapsing them into a single scoring call.

1. 1

   Observation

   A detector reports something concrete: a negotiated key-exchange group, a certificate signature algorithm, a cipher constant in a binary, a named algorithm in a configuration file. The raw observation is stored with its source location. See The detector catalogue.

2. 2

   Normalisation

   The observation is resolved against our algorithm register to a canonical primitive and parameter set. This is where “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256” becomes a set of separately scored primitives rather than one opaque string.

3. 3

   Dimension scoring

   Each of the five dimensions is matched to a rubric anchor and given a value with a provenance class. Anything Assumed is flagged here, not later.

4. 4

   Aggregation

   The published weights are applied and the result is rounded half-up. Both the pre-rounding and post-rounding values are kept, because a 64.5 and a 65 have different tiers and a reviewer should be able to see that.

5. 5

   Floor check and tiering

   The fragility floor is evaluated. The band lookup then assigns one of the four tiers. If the floor changed the outcome, the record shows the unfloored score alongside the final one.

6. 6

   Sealing

   The record is hashed and the digest is written to the Evidence Ledger. Later edits create new versions; they do not alter what was sealed.

#Reading a finding

The record below is illustrative and uses the worked asset from How the exposure score is built. Field names are shown in the flat form used by the export rather than the console layout.

finding             F-0000-ILLUSTRATIVE
method_version      [PLACEHOLDER: current method version]
asset               tls-edge-payments-01
owner               [PLACEHOLDER: declared asset owner]

detector            tls handshake observation
observation         key exchange negotiated RSA key transport, 2048-bit
evidence            stored transcript metadata, no plaintext retained
primitive           RSA-2048, key transport

primitive_fragility     100   observed   anchor: Shor-defeated asymmetric primitive
confidentiality_horizon  95   declared   anchor: statutory retention beyond 20 years
reachability            100   observed   anchor: internet-facing listener
change_cost              65   derived    anchor: external counterparty coordination
substitution_gap         30   derived    anchor: FIPS 203 replacement, hybrid mode shipped

raw_score           86.50
final_score         87
floor_applied       no
tier                Acute

first_seen          [PLACEHOLDER: first-seen date]
last_confirmed      [PLACEHOLDER: last-confirmed date]
overrides           none
evidence_digest     sealed to the Evidence Ledger

Everything needed to reproduce the 87 is on that record: five values, five weights published in the method, one rounding rule and one floor rule. Nothing in the chain requires access to our systems to verify. That is the property we optimise for, and it is why the scoring path contains no model output that cannot be restated as a rule.

#How to contest a finding

Disagreement is expected and it is useful to us. A contested finding is either an error we should fix or a scope question we should have asked at intake, and both are worth knowing about.

1. 01Identify the step in the evidence chain you disagree with, and the specific field. “Reachability is 100 but this listener is bound to a management VRF” is actionable. “The score is too high” is not.
2. 02Say what the correct value is and what evidence supports it. Configuration extracts, network policy and a retention schedule are the three that resolve most disputes.
3. 03Raise it through your engagement channel, or via Contact if you do not have one open. A reviewer from our side is assigned and named.
4. 04The reviewer either accepts the correction, applies it as a recorded override and re-scores, or explains in writing why the original value stands. Both outcomes are written to the finding.
5. 05If the disagreement is about the rubric itself rather than about your estate, it is logged as a method issue and considered at the next version review rather than fixed for one customer.

Response time for a contested finding during an active engagement is [PLACEHOLDER: contested finding response commitment]. We do not offer a response commitment outside an active engagement.

#How an override is recorded

An override changes a score. It never deletes one. The original computed value stays on the record, the override sits beside it with an author and a reason, and both are sealed. An estate whose overrides are invisible has no auditable score, so we treat the override log as part of the evidence rather than as an administrative detail.

Every override is visible in the export handed to an auditor, including the ones that lowered a score. See What to hand an auditor for the shape of that package, and Cryptographic bills of material for how findings and overrides appear in a CBOM.