Design Decisions

Design Decisions

This page is explanatory. Canonical support for these decisions is spread across the public repository. When the motivation is not fully documented, it is marked accordingly.

Overlay instead of fork

Documented rationale: MiniCISO keeps Hermes updateable with lower friction while versioning prompts, profiles, templates, and policy as a separate product layer.

Canonical reference: docs/repo-architecture.md

Separate profiles

Documented rationale: the profile set enables specialization, bounded roles, and cleaner handoffs across threat modeling, architecture, code review, AppSec, compliance, offensive validation, recon, and QA.

Canonical reference: docs/profile-setup.md

Chief of Staff coordinator

Documented rationale: a dedicated coordinator handles routing, handoffs, QA enforcement, and final synthesis.

Canonical reference: docs/staff-operating-model.md

Mandatory Security QA

Documented rationale: final reports must pass through security-qa to improve scope control, evidence discipline, clarity, safety, and actionability.

Canonical reference: docs/staff-operating-model.md

Recon is not a finding

Documented rationale: discovery signals alone are insufficient to support a vulnerability claim or report draft.

Canonical reference: docs/kag-finding-validation.md

Evidence before narrative

Documented rationale: MiniCISO explicitly separates evidence layers and blocks unsupported inference.

Canonical reference: docs/staff-operating-model.md

KAG

Documented rationale: selective retrieval helps reduce irrelevant context when structured artifacts are large, but raw-authoritative review still governs final claims.

Canonical reference: docs/headroom-kag-selective-retrieval.md

Headroom

Documented rationale: Headroom is the selection-first mechanism for structural indexing, query shaping, and minimal retrieval-pack generation.

Canonical reference: docs/headroom-kag-selective-retrieval.md

Fewer intermediate reports

Status: not yet documented as a standalone design decision in the public repo.

The operating model implies a preference for coordinated synthesis over uncontrolled partial outputs, but the rationale is not yet documented in a dedicated canonical note.

Repository documentation versus wiki documentation

Documented rationale: normative, version-sensitive content remains in the repository; explanatory, navigational, and editorial content belongs in the wiki.

Canonical reference: docs/readme-docs-wiki-boundary.md