K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / en (hub)

K0NSULT — System for analysis, mapping and countering cyber & AI incidents

One chain from report to hardened resilience. Instead of scattered alerts — a single joined-up process: evidence, classification, risk, playbook, action, validation, report. Built for the security teams of banks and essential entities (NIS2 / national cybersecurity law).

Claim ≤ Proof. No assertion exceeds the strength of its evidence.

The portal never raises an alarm without backing. Every incident carries an evidence status, and every closure requires proof of remediation. This is a GRC/SOC console, not a rumour board of threats.

CHAIN: REPORTEVIDENCESTATUSCLASSIFYRISKPLAYBOOKACTIONVALIDATEREPORTRESILIENCE
NOTE — demonstration environment. Figures and incidents on this portal marked SIMULATION are illustrative (demo). Regulatory frames (EU AI Act, NIS2, national cybersecurity law, GDPR) are based on the publicly known text of the law and are marked as norm/framework. Nothing here is a report of a real breach at a named entity unless explicitly marked CONFIRMED with evidence.

Evidence-first — claim ≤ proof

The system carries one currency of trust: evidence. An alert without evidence is a hypothesis (status GAP), not a fact. Every factual statement is bound to an evidence status, and no incident is closed without proof of repair. This is the rule that separates a GRC console from a fear board. See the full doctrine on Evidence-first.

4 levels of analysis

The system does not artificially split "cyber" from "AI" — it treats AI incidents as a first-class class of security events, with their own legal flags and playbooks.

1 · Classic cyber L1

Phishing, ransomware, DDoS, malware, vulnerabilities (CVE), credential theft, supply chain, misconfiguration.

2 · AI / agentic incidents L2

Prompt injection, agent hijack, data poisoning, model extraction, consequential hallucination, spoofed agent identity, missing human-in-the-loop oversight.

3 · Legal breaches L3

AI Act (art. 73 — serious incident), NIS2 (24h / 72h / final report), national cybersecurity law, GDPR (art. 33/34). Automatic reporting-duty flags.

4 · Resilience / continuity L4

Backup, DR, "Point Zero", network segmentation, PQC (post-quantum cryptography). Closing the loop: incident → strengthened resilience.

6 system modules

Incident Intake

Registration of reports: form, OSINT, SIEM log, CERT bulletin. Assigns a public_id and an intake status.

Evidence Layer

Evidence layer: URL, screenshot, SHA-256 hash, log, IoC, CVE, chain of custody. Confidence level 0–100.

Classification Engine

Type, level (L1–L4), severity, legal flags, priority P0–P3. Deterministic rules + analyst verification.

Threat Map

Visualisation of incidents over time and sectoral space. Cyber Map and AI Risk Map.

Playbook Engine

Playbook selection by type and priority. Response steps, validation criteria, human-in-the-loop for P0/P1.

Legal / Compliance Engine

Mapping to duties: AI Act, NIS2, national cybersecurity law, GDPR. Reporting clocks, export of the report to the authority.

Process chain — from report to resilience

1REPORT / intake 2EVIDENCE / hash + custody 3STATUS / evidence status 4CLASSIFY / L1–L4, P0–P3 5RISK / severity + flags 6PLAYBOOK 7ACTION / logged 8VALIDATE 9REPORT / to authority

Operational KPIs SIMULATION

The values below are demonstration data — they illustrate the console format, not the state of any real infrastructure.

128
Reports (30 days)
demo · all sources
7
Open P0/P1
demo · SLA active
94%
Incidents with evidence
demo · evidence coverage
3
AI_SERIOUS_INCIDENT flags
demo · AI Act art. 73
2h11m
Median MTTA P0
demo · time-to-acknowledge
18h
Median MTTC P1
demo · time-to-contain

Who is it for

Banks and financial institutions

Essential entities under NIS2 / national law. Mapping incidents to DORA-adjacent duties, 24h/72h clocks, final report. An audit trail for the financial supervisor and national CSIRT.

→ Banking security demo

SOC / response teams

Intake → classification → playbook in one chain. P0–P3 priorities with SLA. A Response Board as the duty console.

→ Sentinel attack/defense

Compliance / DPO / regulator

A Legal Board with reporting-duty flags. Evidence-first as the basis of credibility before the supervisory authority (GDPR art. 33/34, AI Act art. 73).

→ Evidence doctrine

Global developer & security community

Coders, red/blue teams and researchers worldwide. Methodology-level attack/defense modelling (MITRE ATT&CK, kill chain, PTES, OWASP) — proof over spectacle.

→ National Attack/Defense hackathon

What is proven vs planned (evidence-first on ourselves)

The doctrine applies to our own claims too. We label maturity honestly:

ClaimStatusWhat it really means
Roster of ~50,000 specialistsDATAModeled roster in a ledger (52,549 records) — data, not live agents.
Executable swarm runningLIVEReal infrastructure: ~16 parallel / up to 1000 per workflow. Swarm ≠ registry.
~50 partner pentesters (instytucji finansowej)PLANNEDAnonymous, invited; confirmed only after a signed RoE. No bank name until then.
5k/10k agents per cycle, 15× metaGOROADMAPOrchestration doctrine, not current state.

English flagship map

Full Polish set

Hub · Dashboard · Threat Map · Playbooks · Compliance

Overriding principle. The portal has one currency of trust: evidence. An alert without evidence is a hypothesis (status GAP), not a fact. Closing an incident without proof of remediation is not allowed. This is what separates a GRC console from a fear board.