INTEL128

INTEL128 · DOCS · SCHEMA

The claim schema

Every PeriscopeCTI output is a set of claims. Seven fields define one claim, and three of them are the reason it can be verified.

Claim = {
  subject:         {text, type, normalized_id?},
  relation:        string,
  object:          {text, type, normalized_id?},
  evidence:        [{document_id, quote, start, end}],
  epistemic_status: explicit | inferred | uncertain,
  confidence:      optional model score,
  review_status:   proposed | accepted | edited | rejected | uncertain
}

Fields

FieldMeans
subject, objectThe two mentions the claim connects, each with an entity type. normalized_id is optional and holds a reference identifier when one resolves.
relationThe typed predicate between them. Examples: uses, targets, exploits, indicates, attributed_to. Not a fixed ontology in this version.
evidenceOne or more spans in the source document: the exact quote plus its start and end offsets, tied to a document_id.
epistemic_statusWhether the report states the claim, implies it, or leaves it unclear. See below.
confidenceAn optional model score. It is a score, not a calibrated probability, unless calibration is explicitly evaluated.
review_statusWhere the claim sits in analyst review. See below.

Entity types

Subjects and objects are typed. The working set is malware, tool, threat actor or group, vulnerability, campaign, observable or indicator, organization, and other.

Epistemic status

ValueMeans
explicitThe source text states the claim directly.
inferredThe claim is derived by reasoning over the text, not read from it.
uncertainThe text is ambiguous, conflicting, or incomplete on this point.

This field is the difference between a factual record and a hedge. A claim that a group "used a web shell for persistence" is explicit when the report says so; an ATT&CK technique mapping drawn from that sentence is at best inferred, and is marked as such.

Review status

ValueMeans
proposedThe model produced the claim; no analyst has touched it.
acceptedA reviewer confirmed it against the evidence.
editedA reviewer corrected the entity, relation, or identifier.
rejectedA reviewer found the evidence does not support it.
uncertainA reviewer could not resolve it either way.

Approved exports include only analyst-accepted items by default, and preserve their provenance and review history.

What the validator checks

The model proposes records. Deterministic software then checks them, and an invalid output is rejected or queued for repair, never silently accepted. The checks are:

A human reviewer then judges whether the cited text actually supports the asserted relation and any ATT&CK mapping. That judgment is recorded separately from the model output.

Abstention

The system may return an abstention instead of a claim when the evidence is insufficient. That is a recorded outcome, not an empty result: it says the passage was read, and the text did not support a claim. Abstention is measured deliberately, because a system that guesses silently and a system that declines visibly are not the same product.

Relationship to STIX

This is a PeriscopeCTI research schema. It is not a complete STIX 2.1 object model, and no export is described as STIX-conformant until it passes validation with a STIX library and interoperability tests. The normalized_id fields are the bridge: they let a claim point at a version-pinned identifier (for example an ATT&CK technique) without claiming full STIX coverage.

Next: How we evaluate →

See the schema in a real extraction.

Request a research preview of PeriscopeCTI and we will walk through a report, its claims, and their evidence spans.

Request a research preview