Build in development
Choose a starting task
Use the case records and design references to produce an evidence critique, a mapping proposal or a small world-state experiment plan.
Three ways to begin
Start with the linked materials and record your own analysis. Runnable instructions, implementation repository access, dependencies and supported platforms will be added after code review.
Threat research and intelligence
Starting material: the ShieldBreak action records and their archived sources.
- Read M3, the content-substitution example. Identify what the attacker controls, what the engine does and what changes.
- Follow the evidence. Compare the reported behavior with each modeled condition and resulting state.
- Write a competing interpretation or specify the observation that would resolve an evidence gap.
Your output: an annotated action record or evidence critique, with claims linked to sources and assumptions stated explicitly.
Prepare an analysis contribution · Get the records
Detection engineering and TTP mapping
Starting material: one chosen action, a catalog reference with its identifier and version, and the draft integration matrices as guidance on mapping relations.
- Identify a condition or effect of the action that a sensor could observe.
- Create a mapping proposal between that action and your chosen catalog entry. Name the relation, explain the match, and retain the external identifier and version. The site's retained ATT&CK crosswalk uses historical v19.2.
- Describe the required telemetry, collection context and a test that could distinguish the behavior from an alternative explanation.
Your output: a mapping and detection-test proposal with an explicit observation and acceptance criterion. A useful proposal names what would make the mapping or detector fail.
Read the observability question · Prepare a tooling contribution
Basic semantic world-state exploration
Starting material: the reference architecture, one case action and the dated component evidence.
- Choose one source-backed claim and one changed premise, such as removing the content-substitution contribution.
- Describe the input record, the compiler's expected consequence and the separate decision about accepting a revision.
- Write the query result expected before and after that revision. Include source, time and context qualifications, guided by the documented implementation failures.
Your output: a small experiment plan specifying inputs, expected revisions, queries and checks for implementation review.
Follow the model, system and compiler responsibilities
Work from an inspectable record
The M3 example connects a plain-language explanation to its formal fields and archived evidence. Keep those connections in your own proposal so another reader can examine the same basis.
Supporting downloads
| Artifact | Description |
|---|
| Analysis presentation | The data the interactive case displays. |
| Selected formal records | M3 (content substitution), M4 (object-path redirection), N3 (junction-path redirection), and C2, the comparison group the three share. |
| Fuller formal model | The broader case records with their dependency edges (the links that show one action supplying a condition another needs) and defensive profiles (where a defense could act on each action). |
| Model changes | Editorial corrections, and material omitted from the public projection. |
| Source registry | Citations and archival access details. |
| Presentation schema | The structure the case presentation expects. |
Artifact versions and compatibility
Artifacts included in this draft. The YAML downloads use JSON syntax, compatible with YAML 1.2.| Artifact | Version and status | Use and compatibility |
|---|
| Analysis presentation · JSON | Presentation draft 0.2.1 · case revision local-draft-3 · 7 October 2026. | Data behind the prepared analysis, with its own presentation version. |
|---|
| Curated formal slice · YAML | Slice local-draft-3 · based on archival source 0.4.0, dated 5 September 2026. Selected public records from the archive. | M3, M4, N3 and C2 retain their normalized formal values and qualifications. MC-SPEC 0.4.19-draft / mc-core 0.4.20.1 bindings remain provisional. |
|---|
| Fuller formal model · YAML | Local review correction in 0.2.1, based on archival source 0.4.0. Local publication revision. | Retains the model’s ontology terms, clause structure, defensive profiles and enablement graph. Source-based requirements remain inferred and unmeasured; ontology bindings remain provisional. |
|---|
| Model changes and omissions · JSON | Source hash and explicit correction record accompanying the fuller model. | Distinguishes preserved archival content from provenance corrections and publication omissions. The unchanged original is retained locally. |
|---|
| Source registry · JSON | Curated references for this draft; snapshot metadata is carried in the file. | Trace a claim to its source and retrieval context. Retrieval context helps assess whether sources provide independent support. |
|---|
| Presentation schema · JSON | Draft schema paired with the analysis presentation. | Checks presentation structure; semantic interpretation is reviewed against the records and their sources. |
|---|
Availability and reuse
The downloads support reading and local experiments. Each artifact's details retain its version, provisional specification/ontology bindings and use conditions. Third-party material keeps its own attribution and rights.