Governance documentation in NeoArc is not free-form text. It uses typed content blocks with structured data fields, each of which can be linked to architectural nodes in the Intent Graph. This structure is what makes automated governance measurement possible: the system can count how many risk blocks govern model entities, or which schemas lack security control coverage, because the blocks and their relationships are machine-readable.
Entity Blocks and the Governs Edge
Content blocks with semanticKind: 'entity' can hold node references. Each reference creates a governs edge in the Intent Graph from the block to the target architectural node. These references include the node ID, type, label, a relationship descriptor, and structural hash metadata for drift detection.
When governance rules are enabled, the system evaluates these references against the rules. A risk block that governs three model entities satisfies the "risks must govern data entities" rule for those three entities.
Risk and Security Blocks
Risk
Individual risk documentation with likelihood, impact, mitigation strategy, and residual risk. Links to model entities, schemas, or endpoints to declare which parts of the architecture the risk applies to.
Risk Register
Tabular format for documenting multiple risks in a single block. Each row is a risk with its assessment and mitigation. Useful for teams that prefer a consolidated risk view per page.
Security Control
Security control definitions with implementation details. Links to model entities, schemas, REST endpoints, and REST APIs to declare what the control protects. Required by both SOC2 and ISO 27001 rule sets.
Security Threat Model
Structured threat modelling with threat actors, attack vectors, and countermeasures. Links to model entities to declare which data assets the threat analysis covers. Required by ISO 27001 rules.
Failure Scenario
Failure mode documentation describing what can go wrong, the probability, the impact, and the response. Useful for resilience planning and connecting failure modes to specific architectural components.
Scenario (What-If)
What-if scenario analysis for exploring potential situations and their architectural implications. Supports structured reasoning about edge cases and boundary conditions.
Compliance and Governance Blocks
Compliance Requirement
Regulatory or contractual compliance requirements with reference identifiers, descriptions, and verification criteria. Links to model entities to establish regulatory traceability. Required by SOC2 rules.
Governance Checklist
Structured checklists for governance audits with items, pass/fail status, and notes. Links to REST endpoints to declare which endpoints have been audited. Required by ISO 27001 rules.
Data Lifecycle
Documents the stages of data progression: ingestion, processing, storage, archival, deletion. Links to model entities to declare which data assets follow this lifecycle. Required by SOC2 rules.
Data Dictionary
Data element definitions with names, types, descriptions, and business rules. Links to schemas to associate data definitions with their structural representation. Required by ISO 27001 rules.
Decision and Constraint Blocks
NFR (Non-Functional Requirement)
Performance, scalability, availability, and other quality requirements with measurable criteria. Links to model entities to declare which parts of the architecture the NFR constrains. Part of the General rule set.
Assumption
Project assumptions that underpin architectural decisions. Links to model entities to make assumptions traceable to the entities they relate to. Part of the General rule set.
Constraint
Limitations that bound the solution space, whether technical, regulatory, or organisational. Links to schemas to declare which data structures the constraint restricts. Part of the General rule set.
Principle
Guiding design and architecture principles that inform decisions. While not part of the built-in governance rules, principles can still hold node references and participate in custom governance rules.
Operational Governance Blocks
Incident Response Plan
Incident response procedures with escalation paths, communication plans, and recovery steps. Links to REST endpoints to declare which API boundaries the plan covers. Required by SOC2 rules.
Operational Runbook
Step-by-step operational procedures for common tasks and failure scenarios. Can reference architectural nodes to associate runbooks with the components they operate.
Additional Traceability Blocks
Several other block types support governance through traceability rather than direct governs edges.
| Block Type | Governance Contribution |
|---|
| Requirement Traceability | Maps requirements to implementation elements, creating a traceability matrix for audit |
| Quality Gate | Defines pass/fail criteria for architectural milestones, supporting stage-gate governance |
| Fitness Function | Architecture fitness functions that can be measured and tracked over time |
| Test Coverage Matrix | Maps test coverage to architectural components, showing which elements are tested |
| Change Impact | Documents the expected impact of a proposed change before it happens |
| Technical Debt | Tracks known technical debt items with severity and remediation plans |
| RACI Matrix | Responsibility assignment for governance decisions and architectural ownership |
