Governance Rules Engine
Define and enforce governance rules that require specific content blocks to reference architectural nodes. Built-in rules cover SOC2, ISO 27001, and general governance, with support for custom rules and real-time compliance indicators.
The governance rules engine is the enforcement layer of NeoArc's governance system. Each rule defines a relationship that must exist: a specific type of content block (such as a risk or security control) must reference a specific type of architectural node (such as a model entity or REST endpoint) via a governs edge in the Intent Graph.
When a rule is enabled, the system continuously evaluates every applicable content block in your workspace. Blocks that reference the required node types are compliant. Blocks that do not are flagged, and the architectural nodes they should govern are reported as uncovered.
How Rules Work
A governance rule has three components: a source block type (the content block that must provide governance), an edge type (always governs), and a target node type (the architectural element that must be governed). When you enable a rule, two things happen:
Built-In Rules
NeoArc ships with built-in governance rules covering three compliance frameworks. All rules are disabled by default - you enable the ones relevant to your organisation. Built-in rules can be toggled on or off but cannot be deleted.
SOC2 Rules
| Rule | Source Block | Target Node | Purpose |
|---|---|---|---|
| Risks must govern data entities | Risk | Model Entity | Verify risk coverage across the data model |
| Security controls must govern data entities | Security Control | Model Entity | Traceability from controls to data assets |
| Security controls must govern REST endpoints | Security Control | REST Endpoint | API-level security coverage |
| Security controls must govern schemas | Security Control | Schema | Link controls to data structure definitions |
| Compliance requirements must govern data entities | Compliance | Model Entity | Regulatory requirement traceability |
| Data lifecycle blocks must govern data entities | Data Lifecycle | Model Entity | Lifecycle documentation completeness |
| Incident response plans must govern REST endpoints | Incident Plan | REST Endpoint | Incident procedures linked to API boundaries |
ISO 27001 Rules
| Rule | Source Block | Target Node | Purpose |
|---|---|---|---|
| Risks must govern REST APIs | Risk | REST API | Risk assessment covers all API surfaces |
| Threat models must govern data entities | Security Threat Model | Model Entity | Threat analysis linked to data assets |
| Security controls must govern REST APIs | Security Control | REST API | Service-level security traceability |
| Data dictionaries must govern schemas | Data Dictionary | Schema | Data definitions linked to structure |
| Governance checklists must govern REST endpoints | Governance | REST Endpoint | Audit coverage across endpoints |
General Rules
| Rule | Source Block | Target Node | Purpose |
|---|---|---|---|
| NFRs must govern data entities | NFR | Model Entity | Non-functional requirements linked to data model |
| Assumptions must govern data entities | Assumption | Model Entity | Assumptions traceable to entities they affect |
| Constraints must govern schemas | Constraint | Schema | Architectural constraints linked to data structures |
Custom Rules
Beyond the built-in rules, you can create custom governance rules for your organisation's specific requirements. A custom rule defines the same three components: source block type, edge type, and target node type. You can tag custom rules with any labels (such as your internal compliance framework names) and enable or disable them independently.
The rule editor is accessed via the 5th tab (Governance Rules) in the Project Editor. The dialog provides dropdowns for source block type (all entity block types, sorted alphabetically) and target node type (all Intent Graph node types, with Model Entity pinned to the top). Tags are added via a chip input with autocomplete suggestions drawn from all existing tags across your rules.
Visual Indicators on Content Blocks
When governance rules are enabled, entity content blocks in the page editor display visual indicators showing their governance status at a glance.
| Status | Indicator | Meaning |
|---|---|---|
| Linked | Green link icon with count | Block has node references and none are stale |
| Stale | Orange refresh icon with count | Block has node references but a target node has changed since the last review |
| Warning | Amber alert icon | Block matches an enabled governance rule but has no node references |
| None | No indicator | No applicable governance rules exist for this block type |
Seeding and Managing Rules
When you first open the Governance Rules tab in a project, it will be empty. Click "Seed Built-in Rules" to populate the built-in rules. From there you can enable the rules relevant to your compliance requirements, create custom rules, and use the tag filter chips to manage visibility across large rule sets. The "Select All" and "Deselect All" buttons apply to the currently filtered view, so you can quickly enable all SOC2 rules by filtering to the SOC2 tag and selecting all.