Customer-Driven AI CTI Project

- Category: CTI
- Source article: https://medium.com/@1200km/customer-driven-ai-cti-project-c0db3cdc1830
- Published: 2026-05-13
- Preserved media: 17 image(s), including cover images, screenshots, diagrams, and infographics where present.
- Preserved technical blocks: 0 code/configuration block(s).
Ecosystem Fit
This page mirrors the original Medium article into the 1200km.com Docusaurus ecosystem. The original article flow, images, screenshots, infographics, and technical blocks are preserved from the export.
Full Workflow Quick Reference

Most cyber threat intelligence programs fail at the same point: they produce reports nobody uses. The analyst delivers a threat summary; the SOC ignores it; the CISO asks why the budget exists. The gap is not effort — it is structure. Intelligence that cannot be traced from a customer decision all the way to a fired detection rule, a tuned alert, and a measurable outcome is not intelligence. It is research.
This project template exists to close that gap. It is a 15-phase, gate-controlled methodology for delivering CTI that ends in production detections, executive metrics, and a customer who can articulate exactly what changed in their security posture. AI accelerates every phase — source extraction, hypothesis generation, detection drafting, report writing — but the methodology enforces analytic discipline that no AI can shortcut: source rating, evidence labeling, confidence calibration, quality gate sign-off, and chain integrity from the first PIR to the last deliverable.
The project is published across three foundational articles and this workflow reference.
The Four Articles
Part 1: Foundationsestablishes the analytic standards the entire methodology depends on. Read it before anything else. It defines theClaim-to-Action Chain— the backbone that connects every source claim to a customer decision — and the vocabulary every phase uses:PIR and SIR format,Source Reliability using the Admiralty Code,Evidence Labels,Detection Readiness Levels,Threat Scenario Priority Scoring,Confidence Language,ATT&CK and D3FEND Mapping Quality, and theAI Governance Modelthat controls what AI can and cannot do at each phase.
[Customer-Driven AI CTI Project Template. Part 1: Foundations From pure CTI to hands-on detection engineering with strict validation gates
Part 2A: Phase-by-Phase Execution Guideis the operational core. It walks all 15 phases in sequence — from Phase 0 (project charter and metric floors) through Phase 14 (continuous improvement loop) — with activities, register templates, allowed and prohibited AI actions, validation tests, exit criteria, and chain integrity requirements for each phase. If you are running a live project, Part 2A is your primary reference.
[Customer-Driven AI CTI Project Template. Part 2A: Phase-by-Phase Execution Guide From pure CTI to hands-on detection engineering with strict validation gates.
Part 2B: Reference Toolkitcontains everything you pick up and use: tenAI Workflowswith ready-to-run prompts, elevenTask Cardsfor structured human review, sixQuality Gateswith non-waivable and waivable blockers, all master register schemas, a completeworked exampletracing one threat through the full chain, the30/60/90-Day Execution Plan, and theMinimum Viable Customer Deliverychecklist for time-constrained engagements.
[Customer-Driven AI CTI Project Template:Part 2B: Reference Toolkit From pure CTI to hands-on detection engineering with strict validation gates
This articleis the quick-reference layer. It lists every phase as a numbered action checklist — no explanations, no background, just what to do and where to go. Every action links directly to the relevant section in Part 1, Part 2A, or Part 2B. Use it as your daily driver once you have read the foundational articles.
Read First (Once)
Claim-to-Action Chain·PIR and SIR Definitions·Source Reliability and Admiralty Code·Evidence Labels·Detection Readiness Levels·Threat Scenario Priority Scoring·Confidence Language·ATT&CK and D3FEND Mapping Quality·AI Governance Model
See also:Minimum Viable Customer Delivery·30/60/90-Day Execution Plan
Table of content
-
Phase 0: Project Charter and Guardrails
-
Phase 1: Customer Decision and PIR Definition
-
Phase 2: Crown-Jewel and Business-Impact Mapping
-
Phase 3: Telemetry and Data Readiness Assessment
-
Phase 4: External CTI Source Intake and Validation
-
Phase 5: Threat Scenario Development
-
Phase 6: Hypothesis-Driven Threat Hunting Backlog
-
Phase 7: Detection Engineering Design
-
Phase 8: Detection-as-Code Implementation
-
Phase 9: Test Data, Simulation, and Replay
-
Phase 10: SOC Triage and Incident Workflow
-
Phase 11: Pilot Deployment and Tuning
-
Phase 12: Production Deployment
-
Phase 13: Executive and Technical Reporting
-
Phase 14: Continuous Improvement and Maturity Loop
-
Quality Gates
-
Master Registers
-
AI Workflows
-
Task Cards

Phase 0: Project Charter and Guardrails
-
Set success metric floors perPhase 0: coverage = named scenario + minimum DRL; telemetry = named gap; hunts = count + required classification; decisions = named Decision ID + required register status
-
Define TLP 2.0 handling policy and data-sharing constraints
-
List AI tools in use; require Task Card ID + AI Session ID on every AI-assisted output perEvidence Labels
-
Document chosen Admiralty Code convention (FIRST: F = cannot be judged; or EOS: F = proven false) perSource Reliability
-
Get customer sponsor sign-off on charter

Phase 1: Customer Decision and PIR Definition
-
Conduct customer kickoff; extract the business decisions the PIRs must support perPIR and SIR Definitions
-
Draft PIRs in strong format: decision-linked, time-bounded, named customer owner
-
Decompose each PIR into SIRs: answerable, bounded, named data source, evidence type, confidence threshold, owner, due date, closure condition
-
RunAI Workflow 1: Source Extractionon highest-priority sources
-
Challenge PIR quality withTask Card 2: PIR Quality Challenge
-
Submit evidence pack and passGate A: PIR Approval

Phase 2: Crown-Jewel and Business-Impact Mapping
-
List candidate crown jewels; assign business owner and technical owner to each
-
Map regulatoryand contractual exposure per asset (GDPR, PCI, sector-specific)
-
Scorebusiness impact: financial, operational, reputational
-
Get customer owner approval on final crown-jewel list (no self-classification)

Phase 3: Telemetry and Data Readiness Assessment
-
Inventory all telemetry sources against each crown-jewel system
-
AssignDetection Readiness Level (DRL-0 to DRL-9)per observable type
-
Document collection gaps, retention windows, and normalization state
-
RunAI Workflow 2: Customer Relevance Mapping(telemetry coverage angle)
-
Flag any SIR that has no telemetry source at DRL ≥ 2 as a blocker before Phase 5

Phase 4: External CTI Source Intake and Validation
-
Register each source in the Source Register with two-character combined Admiralty rating (e.g., B4, A1) perSource Reliability and Admiralty Code
-
For AI-assisted output: verify traceable primary evidence; if none → rate F6, block from gate decisions; rate underlying source separately
-
Attach Evidence Label (Task Card ID + AI Session ID) to every AI-assisted entry perEvidence Labels
-
IC 1 (Confirmed) is not available for AI-generated claims
-
Resolve all inter-rater disagreements > 1 letter or number before closing phase

Phase 5: Threat Scenario Development
-
Build one threat scenario per crown-jewel / SIR pair
-
Compute Risk Score (RS) perThreat Scenario Priority Scoring
-
Assign analyst confidence (High / Moderate / Low) perConfidence Language
-
Map MITRE ATT&CK technique(s) perATT&CK and D3FEND Mapping Quality
-
Submit evidence pack and passGate B: Scenario Approval

Phase 6: Hypothesis-Driven Threat Hunting Backlog
-
Convert each threat scenario into a hunt hypothesis: actor, technique, observable, data source, expected artifact
-
Prioritize backlog by RS score; assign to hunter with sprint target
-
Submit evidence pack and passGate C: Hunt Approval

Phase 7: Detection Engineering Design
-
Verify targetDRL ≥ 2before writing detection logic — no logic without telemetry
-
Draft detection query or Sigma rule against named data source
-
Map MITRE D3FEND countermeasure perATT&CK and D3FEND Mapping Quality
-
Record detection in Detection Backlog with schema version, data-source dependency, DRL, severity
-
Challenge logic withTask Card 8: Rule Quality Challenge
-
Submit evidence pack and passGate D: Detection Design Approval

Phase 8: Detection-as-Code Implementation
-
Commit detection rule to version-controlled repository (branch-per-rule pattern)
-
Peer review by second engineer; resolve all review findings before merge
-
Run CI/CD pipeline: syntax check, unit test, lint, schema validation
-
Translate rule to target SIEM query perAI Workflow 6: Query Translation
-
Advance DRL to 4 on successful merge and CI pass

Phase 9: Test Data, Simulation, and Replay
-
Obtain or generate test dataset: real log replay, atomic red team, or purple-team exercise
-
RS ≥ 20 or Tier 1 crown jewels → purple-team exercise is mandatory; log result in Purple-Team Test Register
-
Challenge test coverage withTask Card 8: Rule Quality Challenge
-
Record result per detection: Pass / Conditional pass / Fail-tuning gap / Fail-false negative / Deferred
-
Pilot precision isundefined(not zero) when TP = 0 — do not record “0% precision”
-
Log any false negatives in False-Negative Register; log D3FEND countermeasures in D3FEND Mapping Register
-
Advance DRL to 6 on test pass

Phase 10: SOC Triage and Incident Workflow
-
Draft SOC playbook: triage steps, escalation path, containment actions, evidence preservation
-
Define alert severity mapping and SLA thresholds
-
Map each alert to a decision owner and an IR escalation contact
-
CompleteTask Card 9: SOC Playbook Draft
-
Conduct SOC dry-run against the detection; advance DRL to 7 after playbook approved and dry-run completed perDetection Readiness Levels

Phase 11: Pilot Deployment and Tuning
-
Deploy rule to pilot scope (limited asset set or log volume)
-
Measure MTTD, FPR, precision; compare against Phase 0 floor targets
-
Document each FP suppression with rationale; no undocumented tuning
-
Record Detection Health Register entries daily during pilot window
-
Advance DRL to 8 on pilot pass (pilot completed + tuning decision documented) perDetection Readiness Levels
-
Submit evidence pack and passGate E: Production Approval

Phase 12: Production Deployment
-
Merge detection to production branch; tag release
-
Notify SOC: rule name, severity, expected alert volume, escalation path
-
Start 30-day monitoring window per30/60/90-Day Execution Plan
-
ConfirmGate E: Production Approvalevidence pack is filed
-
Advance DRL to 9 after sustained production pass: owner assigned, monitoring active, review date set, rollback and health tracking confirmed perDetection Readiness Levels

Phase 13: Executive and Technical Reporting
-
Compute metrics: MTTD, FPR, precision, RS coverage %, DRL distribution across all active detections
-
Record WIP metric: count of active detections at DRL 2–6 (in-flight, not yet production-ready)
-
Draft executive report: business impact, threat coverage, open gaps, next-quarter priorities
-
Draft technical appendix:Claim-to-Action Chainintegrity table, DRL table, gate evidence pack

Phase 14: Continuous Improvement and Maturity Loop
-
Conduct PIR Feedback Loop meeting with customer; re-score open SIRs
-
Close satisfied SIRs with evidence; document residual risk for unsatisfied SIRs
-
Promote new threat actor TTPs to Phase 1 intake queue
-
CompleteTask Card 11: Final Red-Team Review; resolve all Critical and High findings before Gate F
-
Submit evidence pack and passGate F: Final Delivery Approval

Quality Gates
-
Gate A: PIR Approval— after Phase 1 →Gate A
-
Gate B: Scenario Approval— after Phase 5 →Gate B
-
Gate C: Hunt Approval— after Phase 6 →Gate C
-
Gate D: Detection Design— after Phase 7 →Gate D
-
Gate E: Production— after Phase 11–12 →Gate E
-
Gate F: Final Delivery— after Phase 14 →Gate F
Master Registers
-
PIR / SIR Register— Phase 1 →Phase 1
-
Crown-Jewel Register— Phase 2 →Phase 2
-
Telemetry Register— Phase 3 →Phase 3
-
Source Register— Phase 4 →Phase 4
-
Threat Scenario Register— Phase 5 →Phase 5
-
Hunt Backlog— Phase 6 →Phase 6
-
Detection Backlog— Phase 7 →Phase 7
-
Detection Coverage Gap Register— Phase 7 →Phase 7
-
Detection Register— Phase 7 →Phase 7
-
D3FEND Mapping Register— Phase 7 →Phase 7
-
Purple-Team Test Register— Phase 9 →Phase 9
-
False-Negative Register— Phase 9 →Phase 9
-
Detection Health Register— Phase 11 →Phase 11
-
Final Delivery Package— Phase 14 →Phase 14
AI Workflows
-
AI Workflow 1: Source Extraction— Phases 1 and 4
-
AI Workflow 2: Customer Relevance Mapping— Phases 2 and 3
-
AI Workflow 5: Detection Drafting— Phases 7 and 8
-
AI Workflow 6: Query Translation— Phase 8
-
AI Workflow 7: Test Case Generation— Phase 9
-
AI Workflow 8: SOC Playbook Drafting— Phase 10
-
AI Workflow 9: Report Drafting— Phase 13
-
AI Workflow 10: Quality Review— Phase 14
Task Cards
-
Task Card 1: Source Claim Extraction— Phases 1 and 4
-
Task Card 2: PIR Quality Challenge— Phase 1
-
Task Card 5: Threat Scenario Builder— Phase 5
-
Task Card 7: Detection Logic Draft— Phase 7
-
Task Card 8: Rule Quality Challenge— Phases 7 and 9
-
Task Card 9: SOC Playbook Draft— Phase 10
-
Task Card 10: Executive Report Draft— Phase 13
-
Task Card 11: Final Red-Team Review— Phase 14
Follow for practical cybersecurity research
If you’re interested in**Offensive security,**AI security, real-world attack simulations, CTI, and detection engineering— this is exactly what I focus on.
Stay connected:
→Subscribe on Medium:medium.com/@1200km →Connect on LinkedIn:andrey-pautov →GitHub — tools & labs:github.com/anpa1200 →Contact:1200km@gmail.com