Development and evidence

About 7 min read

Frameworks should show their work: why the phases exist, what earlier design was rejected, where the method has been used, and how much confidence its evidence deserves. This page is that record for ASSURED, starting with the evidence.

What the current evidence establishes

Where the method came from

I came to security operations sideways, from the Army through IT support, network engineering, and a physical security role at Square, and learned triage through a weekly mentorship and one supervised hour a day on lower-complexity cases. That history is not evidence that ASSURED works; it explains the design pressure of crossing the gap between knowing security concepts and making defensible decisions on real events.

ASSURED began during parental leave, while I was comparing incident-response books with the alert-by-alert work of the triage desk. The books treated triage as a brief part of detection and analysis. But an analyst cannot give every alert the depth of a confirmed incident, a weak close can miss an incident, and a weak escalation hands noise to the response team. The missing structure was the work between those points.

The full research log, from the path into triage through the AUSPICED draft, the development method and the Lateral Work Program, is kept in the repository: RESEARCH-LOG.md.

The first design: AUSPICED

The first attempt was AUSPICED. The draft, dated October 2023, is unpublished, so this is the author’s account of it. It failed during writing, before any testing. Its eight parts sat in two domains and four divisions, and the structure was soon doing more work than the analyst. Pattern could not be kept apart from Investigation; Communication belongs throughout the work rather than at one point; nothing named the close-or-escalate decision; and risk had no stage of its own. ASSURED kept what held up:

The result is seven linked decision phases, each with an anchor question, a required output, and a reason to hand the work on. The site launched as 1.0.0 in May 2026, with 1.1.0 and 1.2.0 in July 2026; the changelog records each release.

The method was a practitioner design loop, not a research study: observe the recurring decisions, write them as named stages, reject structures that do not hold, teach and observe, turn claims into inspectable artifacts, and publish for challenge. That is a retrospective description, the teaching step was not logged as it happened, and practitioner knowledge is not empirical validation.

Use in the Lateral Work Program

The Lateral Work Program gives participants supervised exposure to security work while the receiving team routes appropriate cases to them. It runs inside my employer’s security organization; ASSURED is the curriculum I chose for it, not a mandated company standard. Around a dozen participants have come through it, and I have observed them become more confident resolving tickets. That is qualitative observation: confidence can improve while accuracy does not.

The conflict of interest deserves a plain statement. I created the framework, co-lead the program, judge informally how participants are doing, and maintain this site. Every favorable observation here passed through the same interested person, which is exactly what independent scoring and outside replication exist to correct.

Feedback from early teaching and from my own tickets was folded in without a systematic log, so I cannot always say which observation changed which part. From the first release after 1.2.0, each substantive change in the changelog names the observation that prompted it.

Relationship to Investigation Theory

This page exists because of a public critique. In July 2026, shortly after the 1.2.0 release, Chris Sanders pointed out that the related-work claims omitted his prior work and that the site said nothing about how ASSURED was created or tested. He was right on both counts. The related-work map now credits that work, and this page answers the second point.

Sanders’s Investigation Theory, the Creative Choices study, and his dissertation The Analyst Mindset set the standard of documented derivation this page works toward. ASSURED was not derived from them, but they overlap on evidence, questions, bias, and making analyst reasoning teachable. Investigation Theory goes deeper into how investigators think; ASSURED is a narrower operational workflow from alert to a documented close or handoff.

What would count against ASSURED

A framework that cannot say what would disprove it is a brand, not a methodology. These observations would force specific claims to change:

• If blind-scored scenario work shows no improvement in decision quality after instruction, the teachability claim fails as stated.
• If, on cases the depth ladder routes to the full arc (Level 2), experienced analysts routinely skip, merge, or reorder Subject and Scope with no measurable loss of decision or documentation quality, the phase structure is wrong about where the load-bearing boundaries sit. (Levels 0 and 1 compress these phases by design; see the fast path.)
• If a random QA sample of Level 0 closes, re-worked blind at full arc by a second analyst, overturns more than an agreed share of verdicts (or turns up any missed incident), the depth ladder is miscalibrated and its eligibility gate is too permissive.
• If independent teams find the phase outputs do not fit their queue without major restructuring, the claim that the workflow generalizes fails.

If any of these are observed, the changelog will record the observation and the change it forced.

The validation work ahead

The next stage turns practitioner observation into evidence others can inspect, with safeguards built in:

1. Publish the basics: learner counts, cohorts, and instructional periods, in aggregate.
2. Pre-register: freeze the hypotheses, target sample size, analysis plan, and scoring instruments publicly before the study begins.
3. Use two instruments: (a) decision correctness against a sealed answer key (the verdict on both axes, close or escalate, and the criterion named), and (b) a method-neutral documentation rubric that does not reward ASSURED’s own terminology. The teaching guide’s close-note checks and the site’s quizzes are learning aids, not the instrument.
4. Blind the raters: at least two reviewers who did not teach the participant, one from outside the program, score each item without knowing whether it came before or after instruction. Report inter-rater agreement (for example, Cohen’s kappa) and agreement between analysts on verdict, priority, and decision. The facilitator kit’s capstone shows the blind two-rater protocol and agreement worksheet at cohort scale; like the rest of the teaching material, it is a learning aid, not the study instrument.
5. Protect participants: participation is voluntary, with informed consent and the right to opt out; results are reported in aggregate only and never used in performance evaluation.
6. Measure quality, not just speed: use the measures on Measuring triage.
7. Add a comparison arm: compare ASSURED-guided work with the team’s prior process or another explicit approach.
8. Invite replication: independent teams reproduce the training and publish positive and negative findings.

Until that work exists, ASSURED’s claims should stay proportionate: it is an open, structured, versioned, and teachable practitioner methodology with early applied use, not a proven universal standard.