Assessment methodology

Version 1.0 · in force from 3 November 2026 · versioned separately from the terms of service

This page describes how the content we supply produces an assessment: what a class is, what an evaluation does and does not do, what the findings are mapped to, how versions are pinned and recalled, and what we commit to when content turns out to be wrong. It is written for someone deciding whether the output can be relied on, and for their advisers.

1. Why this is a separate document

Section 13 of the terms commits to the shape of an assessment and links here for the detail. The split is deliberate. The detail moves when the published security frameworks we map against move, which is not a change to the bargain between us. Keeping it here means a framework upgrade corrects this page, with its own new version number and date, instead of re-papering the contract and asking every subscriber to accept new terms for an event that changed nothing they agreed to.

So this page carries its own version and its own date, shown in the footer. The terms carry theirs. Where the two ever disagree, the terms govern the contract and this page describes the build.

2. What an assessment is

A class is a technology — a container image, a managed database, an identity provider. Each class has a configuration schema listing the attributes that describe it, the guidance that explains them, a policy, and the test cases that policy must satisfy. Section 3 says which of those your deployment receives and which stay with us.

An assessment is that policy evaluated over the attributes you have declared for one element of your own design. It is a deterministic rule evaluation: the same class, at the same pinned version, over the same attributes, returns structurally identical output every time. It is not a prediction, it is not scored by a machine-learned model, and no language model takes part in it.

We evaluate one element at a time, and we see nothing else. The request carries the attributes of that element and nothing more — not the element's name, not the model it belongs to, not what it connects to, not anything you have written by hand elsewhere. An assessment is therefore a statement about a described configuration, not about your architecture.

An unentitled call is never a clean result. If your subscription does not cover the class, the answer is an explicit not evaluated, carrying its own status. It is never an empty set of findings, because an empty set reads as “evaluated, nothing found” and would silently suppress real exposures.

The same rule holds for failure. If the evaluation itself fails, you get an error. You never get an empty result standing in for one.

3. What every class is built from, and what you receive

Every class in the catalogue has all five of these. Three are delivered to your deployment; two stay on our side, because the evaluation runs on our systems rather than on yours.

Delivered to your deployment:

The class definition — what technology it describes.
A configuration schema — the attributes it declares and their types, which is what your deployment renders as the configuration form you fill in.
Guidance — what each attribute means and how to answer it.

Held by us, and not supplied to you:

A policy — the rules evaluated over those attributes.
Test cases — the inputs and expected outputs the policy must satisfy. We author them with the policy and run them against it; they are not published.

The schema and the guidance are what make the defect definition in section 7 operable. Between them they are the published statement of what a class asks you and what each answer means, and they are what an output can be held against: an assessment that does not follow from the attributes, read as the schema and the guidance define them, is wrong on the face of what we published, and you do not need our policy in your hands to say so. The class version you pinned and the attributes you sent are enough for us to reproduce the run against its test cases — section 8 is what we owe you when you report one.

4. What is in the catalogue

The packages on sale, and what each one covers, are listed on our offerings page; the modules and classes inside each package are listed in the catalogue once you are signed in. That listing changes whenever we publish content, so this page does not repeat it. A package is a set of modules, a module is a set of classes, and each class carries the finding definitions — the exposures and countermeasures — its policy can return.

5. Severity, and the vocabulary a finding may use

Each finding is authored with four fields describing how serious it is and how it is reached. Two distinctions run through them and both are stated, because neither is the same assurance as the other: which fields the service enforces and which are an authoring convention, and which fields an assessment actually delivers to you. A field we author but do not return is not one you can act on, so we say where each stands.

Criticality: One of critical, high, medium or low. Every finding in the published content carries one of those four and nothing else — but an assessment does not return it. It reaches you only through the reference data your deployment fetches, where it sits on the rule, and never on the exposures and countermeasures an evaluation answers with.
Attack vector: One of NETWORK, ADJACENT, LOCAL, PHYSICAL or UNSPECIFIED. This set is enforced by the service: a value outside it is recorded as UNSPECIFIED rather than passed through to you, so a typing mistake in a policy cannot invent a category. It is delivered with an exposure. A countermeasure is authored with one too, and an assessment does not carry it there.
Score: A number authored with the finding and delivered with it. The service does not constrain its range.
Type: Either misconfiguration or vulnerability, delivered with the finding. Those are the only two values in the published content.

6. Framework mapping, and its limits

Findings are mapped to published security frameworks by named identifier, against a stated corpus version:

MITRE ATT&CK v19.2
MITRE D3FEND 1.6.0

Both corpora ship with the open-source platform you run yourself, not with this subscription. Your deployment resolves the identifiers a finding names against the corpus it already holds.

The mapping is not universal, and we will not claim that it is. Some finding definitions in the catalogue name no framework reference at all. A finding with no reference is still a finding; it simply has no published identifier we are willing to assert for it.

A reference is an ATT&CK technique or mitigation, or a D3FEND technique. Many references carry a written justification explaining why that identifier applies to that finding; not all of them do, and those carry the identifier without one.

What we commit to, in the terms, is the mapping's shape: where a finding is mapped, it names published framework identifiers against a stated corpus version. We do not commit to every finding being mapped, and mapping the rest is content work rather than a promise.

7. When content is defective

Content supplied under the subscription is defective if:

the output does not follow from the attributes, as the class's published schema and guidance define them;
guidance cites a control or a framework mapping that does not exist in the corpus version it names; or
a published version is unsafe to act on.

It is not a defect that a real exposure exists which no class covers, or that a finding is unhelpful in your particular environment. Coverage is a matter of what the catalogue contains, and relevance is a matter of judgement about your own systems — neither is a failure of the content against what it says it does. Both halves of this definition matter: without the first there is nothing to answer for, and without the second the completeness disclaimer swallows the first.

8. What we do about a reported defect

We acknowledge within 5 working days of a report reaching support@dether.net.
Within 25 working days we publish a correction, recall the defective version naming the version that supersedes it, or explain why we do not consider it a defect.
The clock runs from that address, not from a remark in a meeting or a message on a social network, so that the obligation is discrete and we can tell when it started.
The clock pauses while we are waiting on you for information we reasonably need to reproduce the problem, and resumes when it arrives.
A version unsafe to act on is withdrawn as soon as we confirm it, without waiting out the 25 days.

This is a commitment about method and response, not about outcome. We do not promise that content is complete or current, or that it identifies every exposure a system carries; output is a contribution to your assessment and does not replace it.

9. Versions, pinning and recall

Every published version of a module's content is addressed by a hash of its own contents and is immutable. Your deployment pins a version, and we cannot change a version you have pinned — a correction is a new version with a new address, never an edit to the one you hold.

We may recall a version we consider defective or unsafe. A recall carries a reason and, where one exists, the version that supersedes it, and your deployment is told both when it next asks for the recalled version. Nothing forces the change on you: you decide when to move the pin, and what you have already fetched keeps working while you decide.

10. There is no update schedule

We publish new and corrected content when it is ready. There is no release cadence, nothing is promised monthly or quarterly, and updating is a manual act on our side and a deliberate one on yours — no version you hold changes without you moving the pin. We would rather say this plainly than publish a frequency we do not operate to.

11. What we hold while we evaluate

The attributes your deployment sends are stripped to the attributes the class's schema declares — anything else in the request is dropped before evaluation — then evaluated in memory. They are never written to storage of any kind and never logged.

What that leaves, stated rather than rounded off. Evaluation processes are kept warm and reused, so the attributes of the last request a process evaluated for a given class remain in that process's memory until it evaluates that class again or the process ends. Nothing reads them in the meantime, nothing writes them anywhere, and there is no interface — administrative, support or otherwise — through which one can be retrieved. We would rather describe that than claim a clearing step we have not built.

We keep one metering line per request — at most two, where a request reaches us without naming your team — for rate limiting and knowing the service is working. It records the environment, the surface, the outcome, your team identifier and one count. Which count depends on what you called: for an evaluation, how many undeclared attributes were dropped; for a query against our knowledge graph — the reference data your deployment searches and cross-references with — how many keys the query named. No line carries both. It never carries the class you asked about, the attributes, the keys themselves, your account identifier, your token or your IP address — so we hold no record of which class you evaluated.

How this fits the rest of what we hold is in our privacy notice. Where the attributes amount to personal data, we handle them on your behalf under our data processing annex.

12. No compliance framework is delivered under this subscription

This must not be inferred from the framework mapping above. ATT&CK and D3FEND are attack and defence knowledge bases; they are not compliance frameworks, and mapping a finding to one of them is not evidence of compliance with anything.

No compliance or regulatory framework — of any kind — is supplied under this subscription. Compliance content is a separate product, sold separately. If you need it, ask us; do not assume a package you already hold contains it.

13. What this page does not do

It does not promise that our content is complete, that the catalogue covers your estate, or that a clean result means a system is secure. It describes a method and the commitments we attach to it. Assessing your own or a client's systems, and every conclusion drawn from our output, remains yours.