k0nsult.cloud / ai-truth / ipIII / doktryna / en

Evidence-first — claim ≤ proof

The doctrine on which the whole system stands: no factual assertion may exceed the strength of its evidence. This is not a marketing slogan — it is a classification rule, enforced by the data schema, the classification engine and the incident-closure criteria.

🇵🇱 Polski 🇬🇧 English Hub Banking demo Engagement

claim ≤ proof

Every sentence that calls something a "breach", an "attack" or a "leak" carries an attached evidence status. The console never renders an assertion more strongly than the gathered material permits. Where evidence is missing, the event lives as GAP — it does not vanish, but nor is it promoted to the rank of fact.

7 evidence statuses

Status is an attribute of the incident (evidence_status) and of each individual piece of evidence. It defines how strongly the event may be spoken of and which actions are permitted.

Badge	Status	Definition	Example
CONFIRMED	Confirmed	A verifiable technical or official proof exists: log, hash, IoC, CERT bulletin, delivery receipt. The claim may be stated directly as fact.	SIEM log + sample hash + correlation with a vendor advisory for an exploited CVE.
MEDIA SIGNAL	Media signal	A press/industry report with no primary technical proof. Treated as an indicator to verify, not as an established fact.	An article about an alleged ransomware event in a sector — with no confirmation at the entity.
PUBLIC CLAIM	Public claim	A statement by a party (ransomware group, entity, supplier). Known author, unknown truth.	A group's leak-site post declaring possession of data.
GAP	Evidence gap	An event reported or suspected but without sufficient proof. Do not close, do not escalate as fact — collect evidence.	A report that "something is wrong with the agent" with no trace and no logs.
DISPUTED	Disputed	Contradictory evidence, or evidence contested by a credible source. Requires resolution before any decision.	An entity denies a leak that a group claims; no resolution yet.
SIMULATION	Simulation / demo	Exercise or demonstration data. Never to be confused with operational data. Every illustrative figure carries this status.	A red-team exercise, demo data on this portal.
INTERNAL	Internal	Material from the organisation's own systems, confidential, with limited visibility. Real proof, but not for publication.	An internal EDR log, a SOC note, a ticket.

No proof ≠ incident absent. The GAP status does not mean "nothing is happening". It means: the event may be real, but it may not yet be presented as fact nor closed. It is protection against two errors at once — the false alarm and the overlooked breach.

Evidence types

The Evidence layer accepts different kinds of material. Each piece has a type, a source, a confidence level (0–100) and an entry in the chain of custody.

Technical — cyber

URL (reference/artefact) · screenshot (with hash) · SHA-256 hash (sample/file) · log (SIEM/EDR/WAF) · IoC (IP, domain, hash, mutex) · CVE (vulnerability identifier) · vendor advisory.

Official / institutional

CERT bulletin (national CSIRT) · ENISA report · delivery receipt / e-delivery (proof of filing to an authority) · a decision/summons from the supervisor.

AI / agentic

Prompt and model response (input/output pair) · agent trace (tool-call trail) · human-in-the-loop decision (who approved/rejected) · guardrail/policy-engine log · data-poisoning artefact.

Confidence level (0–100)

Regardless of status, evidence carries a numeric confidence level. It distinguishes a weak log from a hard correlate. Rule: incident severity and priority may not derive solely from low-confidence evidence.

90–100

Hard

hash + log + correlation

60–89

Strong

single credible artefact

30–59

Circumstantial

requires confirmation

0–29

Weak

does not justify escalation alone

Chain of custody

Every piece of evidence has an immutable, append-only event register — who, when, did what with the material. Stored as chain_of_custody (JSONB). It guarantees integrity before an auditor or authority.

ACQUISITION→HASH→REGISTRATION→ANALYSIS→VERIFICATION→HANDOVER→ARCHIVE

Chain entry — an atomic record: {ts, actor, action, hash_before, hash_after, note}. Modifying material without an entry = loss of evidentiary value.

Integrity — the hash is computed at acquisition and verified on every access. A hash discrepancy raises the status to DISPUTED until resolved.

Visibility — INTERNAL evidence never reaches the public view; exposure only by role.

An incident closes only with proof of remediation

The symmetry of the doctrine: since opening as fact requires proof, so does closing. An incident may not be marked closed/resolved on the mere belief that "it no longer occurs".

Closure condition	Required proof
Root cause removed	Log/patch confirming remediation; confirmation of version/configuration.
No recurrence in the observation window	Telemetry over the monitoring period (e.g. 7–30 days) with no indicators.
Legal duties fulfilled	Delivery receipt / e-delivery of the filing to the authority, if a NIS2/GDPR/AI Act flag is active.
Resilience updated	An entry in the hardening register (detection rule, segmentation, verified backup).

The loop closes on resilience. An incident is not "closed" until the organisation is measurably less exposed to its recurrence. This is the last link of the chain: REPORT → … → RESILIENCE.

Regulatory frames. References to the AI Act (art. 73), NIS2 (24h/72h/final report) and GDPR (art. 33/34) describe the publicly known text of the law as a norm/framework. They are not a description of any specific breach. Concrete incidents on the portal, unless marked CONFIRMED with evidence, are SIMULATION data.