Skip to main content

k# Heptagon

CI PyPI version Python versions License Status Tests Dependencies Python 3.11+

Seven coordinates. Every incident. Verified.

Heptagon is a symbolic, formal, and executable framework for cybersecurity incident response planning and management. It treats every incident record as a seven-coordinate object — and refuses to certify any record that fails to populate all seven.


Table of Contents


Why Heptagon

Incident response today is documented in prose. Plans live in PDFs. Logs live in ticketing systems. There is no formal way to answer the question: "Is this incident record complete?"

Heptagon answers that question by treating a record as a seven-coordinate object. A record missing its intention, its effect, or its lineage position is not complete — and an incomplete record cannot be certified as truthful.

The framework makes three claims falsifiable:

  1. A complete plan has no gaps. Every escalation path in every scenario must be reachable through the reporting chain.
  2. A complete record populates all seven coordinates. No silent omissions.
  3. A signed record cannot be silently modified. Ed25519 signature verification rejects any post-hoc change.

Each claim is enforced by a specific compliance gate. Each gate can fail. Each failure names the specific record and the specific coordinate or field.


Install

pip install heptagon7

Note on naming. The PyPI project is heptagon7 because heptagon was already taken. After installation, both the Python import and the CLI command are heptagon:

import heptagon          # library
heptagon --help          # CLI

For local development:

git clone https://github.com/claythe3ed/heptagon.git
cd heptagon
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

Quick Start (CLI)

# 1. Generate an Ed25519 keypair for signing decisions
heptagon keygen --out ~/.heptagon/my-key.json

# 2. Validate a CIRP plan against the JSON schema
heptagon declare examples/cirp-reference.yaml

# 3. Run the six compliance gates on the plan
heptagon verify examples/cirp-reference.yaml

# 4. Simulate a scenario's escalation
heptagon simulate ransomware --plan examples/cirp-reference.yaml

# 5. Audit an incident log for signature and 7D validity
heptagon audit incidents.jsonl

Every command supports --json for machine-readable output and uses CI-friendly exit codes:

Exit code Meaning
0 Success — all checks passed
1 Plan or log fails a compliance check
2 Invalid input (bad file, unknown scenario, malformed log)

Quick Start (Library)

from heptagon.audit.log import IncidentLog, save_log
from heptagon.audit.signing import Signer
from heptagon.cirp.model import Decision, Evidence

# Create a keypair
signer = Signer.generate()

# Log evidence
log = IncidentLog()
ev = Evidence.from_bytes("soc", "analyst", b"alert-payload", "initial alert")
log.append_evidence(ev)

# Log a signed decision populating all seven coordinates
d = Decision.new(
    actor="cyber_mgmt",
    rationale="isolate host-12 from network",
    evidence_refs=[ev.evidence_id],
    effect_artifacts=[ev.evidence_id],   # F6
    predecessor="response",               # F7
    successors=["crisis_mgmt"],           # F7
    signer=signer,
)
log.append_decision(d)

# Persist
save_log(log, "incidents.jsonl")

Any change to d.rationale, d.evidence_refs, or any other signed field invalidates the signature. The heptagon audit command detects it and names the record.


The Seven Coordinates

An incident record lives in the fiber bundle E = B × F5 × F6 × F7.

Coordinate Name Captured by
B0–B3 Spacetime timestamp, actor, source
F5 Intention Decision.rationale
F6 Effect Decision.effect_artifacts
F7 Lineage Decision.predecessor + successors

A record that omits any coordinate is partial. A partial record is not a truthful record.

See docs/philosophy.md for the full derivation.


The Six Compliance Gates

CIRPModel.verify_all() runs all six gates and returns a consolidated report. Every gate can fail.

# Gate Enforces
1 check_teams_complete All 5 R-C-C-P-T roles present and complete
2 check_reporting_chain Every reporter can reach an executive role
3 check_evidence_completeness Unique hashes, chronological order, valid references
4 check_no_hidden_thing Every source slice reconciles; every decision verifiably signed
5 check_break_glass_logged Every emergency override is marked AND evidenced
6 check_7d_completeness Every record populates all seven coordinates

The gates are composable. Passing all six does not guarantee a plan is correct — but failing any one of them guarantees it is incomplete.


CLI Reference

heptagon declare <plan.yaml>

Validate a plan against the JSON schema and summarize its structure.

$ heptagon declare examples/cirp-reference.yaml
Plan:         reference_cirp (v1.0)
Teams:        5
Stakeholders: 3
Scenarios:    3
Edges:        4

Team roles:
  - crisis_mgmt
  - cyber_mgmt
  - product_owner
  - response
  - third_party
...

heptagon verify <plan.yaml>

Run the six compliance gates. Exit code 0 if all pass.

$ heptagon verify examples/cirp-reference.yaml
Plan:              reference_cirp (v1.0)
All checks passed: False

  [PASS] teams_complete
  [PASS] reporting_chain
  [PASS] evidence_completeness
  [FAIL] no_hidden_thing
          reason: no evidence logged
  [PASS] break_glass_logged
  [PASS] 7d_completeness

heptagon simulate <scenario> --plan <plan.yaml>

Walk a scenario's escalation order through the reporting DAG. Report coverage, gaps, and mandate violations.

$ heptagon simulate ransomware --plan examples/cirp-reference.yaml
Scenario: ransomware
Rounds:   20
Valid:    True
Coverage: 100.00%

Escalation path:
  response -> cyber_mgmt  (1 hops)
  response -> crisis_mgmt  (2 hops)

heptagon keygen --out <path>

Generate an Ed25519 keypair. The private key is written with 0600 permissions.

$ heptagon keygen --out ~/.heptagon/my-key.json
Keypair written to: ~/.heptagon/my-key.json
Algorithm:          ed25519
Public key (hex):   ...64 hex chars...

Keep the private key secure. Back up the file.
The public key is safe to share.

heptagon audit <log.jsonl>

Verify every signature and every 7D record in an incident log.

$ heptagon audit incidents.jsonl
Log:       incidents.jsonl
Evidence:  2
Decisions: 2

Ed25519 valid: 2

OK: True

If a signed record was modified after signing:

$ heptagon audit incidents.jsonl
Log:       incidents.jsonl
Evidence:  2
Decisions: 2

Ed25519 valid: 1
Invalid signatures (1):
  - 79069348-d450-42e9-86f9-cde3e0b43790

OK: False

Incident Log Format

An incident log is a JSONL file. Each line is a self-contained JSON record.

{"type": "evidence", "data": {...}}
{"type": "decision", "data": {...}}

Records are ordered. Append-only semantics are recommended — never rewrite a log once written, only append to it.

Why JSONL:

  • Append-only (perfect for incident logging)
  • Line-level recovery (one corrupt line doesn't destroy the file)
  • Standard format for forensic logs
  • Diff-friendly in version control

Plan Declaration Format

CIRPs are declared in YAML and validated against heptagon/schemas/cirp.schema.json.

name: reference_cirp
version: "1.0"

teams:
  - role: response
    members: [IR lead, SOC analyst 1, forensics eng]
    contact: "+1-555-0101"
    backup: "+1-555-0102"
    mandate: "Fix the breach, rebuild systems, execute recovery."
  # ... 4 more teams ...

reporting_chain:
  - [response, cyber_mgmt]
  - [cyber_mgmt, crisis_mgmt]
  - [third_party, cyber_mgmt]

scenarios:
  - name: ransomware
    triggers: [mass file rename, ransom note]
    escalation: [response, cyber_mgmt, crisis_mgmt]
    key_considerations: [backup integrity, isolate segments]

Full example: examples/cirp-reference.yaml.


Architecture

heptagon/
├── core/symbolic.py         Symbolic layer
│   ├── FiberBundle7D        7D record space
│   ├── MoralSheaf           flabbiness / injective recording
│   ├── Lineage              DAG of reporting structure
│   ├── PresentationOperator who sees what
│   ├── TestimonyOperator    per-component attestation
│   ├── MoralJacobians       responsibility vs. influence
│   └── UnifiedEvaluation    faithfulness metrics
├── cirp/
│   ├── model.py             CIRP primitives + six gates
│   └── yaml_loader.py       plan loading + schema validation
├── schemas/
│   └── cirp.schema.json     JSON Schema (Draft 2020-12)
├── audit/
│   ├── signing.py           Ed25519 signing
│   └── log.py               JSONL incident-log reader/writer
├── cli/main.py              argparse-based CLI
└── simulation/
    ├── internal_simulator.py numpy-only agent simulator
    └── stuxnet_test.py       historical validation

See docs/architecture.md for the full module map, data flow, and gate definitions.


Testing

pytest tests/ -v
Suite Tests Covers
test_symbolic.py 26 Symbolic core: bundle, sheaf, lineage, operators
test_cirp_checks.py 25 Six compliance gates, tabletop validation
test_signing.py 14 Ed25519 lifecycle, tamper detection
test_log_and_audit.py 11 JSONL round-trip, CLI audit behavior
test_cli.py 10 CLI commands, exit codes, JSON output
test_yaml_loader.py 9 Schema validation, round-trip compilation
test_schema_shipping.py 7 Schema ships inside the wheel (v1.0.1 fix)
test_simulation.py 7 Deterministic agent simulator
Total 109

Every gate has at least one test that proves it can fail, not just pass. A check that cannot fail is not a check.

The CI workflow (.github/workflows/ci.yml) runs the full suite on Python 3.11 and 3.12, then builds the wheel, verifies the JSON schema ships inside it, installs it in a fresh venv, and runs the CLI. If the wheel is broken, CI fails before any release.


Design Principles

  1. Falsifiable claims. Every feature can be tested. If a claim cannot be tested, it does not belong in this codebase.

  2. Honest limits. The threat model states what the framework protects against, and — critically — what it does not.

  3. Standard cryptography. Ed25519 via PyNaCl. No custom crypto, no roll-your-own primitives.

  4. Minimal dependencies. numpy, PyYAML, jsonschema, PyNaCl. Nothing else.

  5. Python 3.11+. Modern typing syntax, no legacy compatibility burden.


Honest Limits

What Heptagon protects against:

  • Accidental omission of evidence or decisions
  • Post-hoc modification of a signed record
  • Unreachable escalation paths in a plan
  • Plans missing required teams or reporting edges

What Heptagon does NOT protect against:

  • A compromised signing key — if the attacker has the private key, they can forge signatures
  • A malicious insider with write access to the audit log — they can delete records
  • A determined attacker with control of the audit machine
  • Legal admissibility disputes — cryptography is valid; admissibility depends on jurisdiction
  • Real-time detection — Heptagon reads logs after the fact
  • Threat intelligence — Heptagon does not track adversaries

Full threat model: docs/threat-model.md.


Contributing

Issues and pull requests are welcome at github.com/claythe3ed/heptagon.

Guidelines:

  • Every feature must have a test that proves it can fail.
  • Every claim in the README must be backed by code.
  • No new dependencies without discussion.

Citation

If you use Heptagon in research or security work, please cite:

@software{heptagon2026,
  author = {Muhammad Ali},
  title  = {Heptagon: Seven coordinates. Every incident. Verified.},
  year   = {2026},
  url    = {https://github.com/claythe3ed/heptagon},
  note   = {PyPI: heptagon7}
}

License

MIT. See LICENSE.

Metadata

Release files for heptagon7 1.1.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for heptagon7 1.1.0
File Size Uploaded Provenance
heptagon7-1.1.0.tar.gz 54.5 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for heptagon7 1.1.0
File Interpreter ABI Platform
heptagon7-1.1.0-py3-none-any.whl Python 3 none any Details

Total release size: 96.6 kB

Release files / heptagon7-1.1.0.tar.gz

Download URL heptagon7-1.1.0.tar.gz
Size 54.5 kB
Tags Source
SHA-256 checksum
How to use checksums
f7d7edad9bee03b523d41c8fec0b1e9c3ad0e880332165b6282621c3432bb977
BLAKE2b-256 checksum
How to use checksums
233a49b144ac4c9abfc6e147424d37171b141dfd39e8e5dc41d3e96612bcb542
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.

Transparency log

Release files / heptagon7-1.1.0-py3-none-any.whl

Download URL heptagon7-1.1.0-py3-none-any.whl
Size 42.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
46a950ddeb954a6d6b342448655919d738ea4ba78c3381a090f40354145932e5
BLAKE2b-256 checksum
How to use checksums
90345386b57601c67ab1f8ba30a0f7f9078f50e9b5cfd85b8d96d65f7b911b1d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.

Transparency log

Security for heptagon7 1.1.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for heptagon7-1.1.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Release history Release notifications | RSS feed

This release

1.1.0 This release

2 release files Full provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page