Architectural Governance
Purpose & Scope
This document governs the structural integrity of the NeuroSaeculum (NS) architecture.
It exists to:
- prevent architectural drift
- enforce clean boundaries between components
- govern how concepts evolve, merge, or retire
- support consistent auditing as the system grows
This document applies to all NS components, including:
- Fields
- Tools
- Systems
- Outputs
- Cross-component references
Out of Scope
This document does not govern:
- tone or writing style
- audience targeting
- visual design
- navigation or site layout
- content completeness
Those concerns are governed by:
- Editorial & Design Guide
- Web Architecture
- Audience Map & 3-Layer Model
Architectural Primitives
All governance rules assume the following primitives.
Fields
A Field defines a domain of inquiry:
a way of seeing, categorizing, and framing signals.
Fields are epistemic, not operational.
Examples:
- Hidden Circuitry
- Cortex
- Civic Topology
- First Foundation
- CivMMI
- Renewal
Tools
A Tool is an operational component that performs a repeatable action within the representational space defined by one or more Fields.
Tools are procedural.
Examples:
- CT Monitor
- CTM
- Narrative Vectors
- Scenario Engine
Systems
A System persists outcomes across time.
Systems accumulate, retain, and reflect learning or state.
Systems are temporal, not analytical.
Examples:
- CivMMI (system aspects)
- Renewal (system aspects)
- LCR Log
Outputs
An Output is the boundary artifact produced by a Field, Tool, or System.
Outputs belong to the component that produces them, not to the component that consumes them.
Boundary Rules
(Structural correctness)
Boundary Rules define what each component may and must not do.
Field Boundary Rules
Allowed Responsibilities (Fields MAY)
Fields may:
- define what counts as an observation or signal
- define categories, domains, and conceptual boundaries
- define legitimate questions
- define the shape of downstream inputs
- describe relationships to other Fields
- describe relationships to Tools and Systems
- list descriptive outputs
Forbidden Responsibilities (Fields MUST NOT)
Fields must not:
- diagnose
- infer causality
- assign severity or priority
- recommend action
- evaluate outcomes
- validate themselves
- accumulate learning over time
- describe internal machinery or algorithms
Verb Discipline (Fields)
Allowed verbs
- observe
- sense
- define
- structure
- normalize
- categorize
- contextualize
- frame
Forbidden verbs
- diagnose
- explain
- determine
- assess
- evaluate
- conclude
- validate
- decide
If a Field page requires forbidden verbs, the responsibility belongs downstream.
Tool Boundary Rules
Allowed Responsibilities (Tools MAY)
Tools may:
- consume Field outputs
- perform analysis, diagnosis, translation, or scoring
- apply formal methodologies
- generate evaluative outputs
- depend on multiple Fields
- be replaced or reimplemented independently
Forbidden Responsibilities (Tools MUST NOT)
Tools must not:
- redefine Field concepts
- expand Field scope
- introduce new ontologies
- claim conceptual authority
- accumulate long-term institutional memory
If a page describes procedures, pipelines, or algorithms, it is not a Field page.
System Boundary Rules
Allowed Responsibilities (Systems MAY)
Systems may:
- accumulate Tool outputs
- track change over time
- retain institutional memory
- reflect maturity or recovery
- provide retrospective insight
Forbidden Responsibilities (Systems MUST NOT)
Systems must not:
- perform real-time analysis
- diagnose or infer causality
- redefine upstream logic
- generate new observations
- intervene directly
Output Ownership Rules
- Field outputs must be descriptive only
- Tool outputs may be diagnostic or evaluative
- System outputs may be retrospective or longitudinal
If an output implies judgment, priority, or explanation, it cannot belong to a Field.
Upstream / Downstream Integrity Rule
Upstream components must not imply downstream reasoning.
Prohibited patterns:
- real-time layers referencing historical validation
- perceptual layers foreshadowing conclusions
- upstream components implying recovery or outcomes
If a reader can infer “and therefore…”, the boundary is violated.
Lifecycle Rules
(Evolution over time)
Lifecycle Rules govern how components change without breaking architecture.
Canonical Lifecycle States
Every component exists in one state at a time:
- Emergent
- Exploratory (v0.x)
- Stabilized (v1.0)
- Refined (v1.x)
- Recomposed (v2.0)
- Absorbed
- Retired
Components must not implicitly exist in multiple states.
Versioning Rule
Version numbers are architectural signals, not marketing labels.
- v0.x → exploratory, non-canonical
- v1.0 → boundaries fixed
- v1.x → refinement only
- v2.0 → structural responsibility change
If responsibility, scope, or temporal role changes, a major version is required.
Absorption Rule
A concept may be absorbed when:
- it no longer has a unique boundary
- its function is better expressed elsewhere
- its name causes confusion
When absorbed:
- it must be removed from upstream definitions
- it must not appear as an active actor
- history may live only in retrospective contexts
Absorption is not renaming.
Retirement Rule
A concept may be retired when:
- it no longer explains active architecture
- it survives only as historical justification
Retired concepts:
- must not appear on Field, Tool, or System pages
- may appear only in historical documentation
Split & Recomposition Rule
Splits occur when:
- one concept spans perceptual and evaluative roles
- one concept spans real-time and long-arc functions
Splits require:
- clean new boundaries
- redistribution of responsibilities
- retirement or absorption of old terminology
- major versioning
Upstream Cleansing Rule
When downstream components evolve:
- upstream pages must be audited
- references must be trimmed or removed
- no compatibility language is allowed
Upstream clarity overrides continuity.
Historical Containment Rule
Historical explanations may appear only in:
- Volume 0
- Architecture evolution notes
- Retrospective essays
- Internal documentation
They must not appear in operational definitions.
Lifecycle Audit Triggers
Lifecycle audits are mandatory when:
- a component reaches v1.0
- a concept is absorbed or retired
- a major version occurs
- a temporal role changes
Drift & Hygiene Rules
(Ongoing correctness)
Drift is gradual architectural degradation caused by growth and hindsight.
Drift is expected. Hygiene corrects it.
Drift Detection Principle
If a page is harder to place architecturally than before, drift has occurred.
Verb Hygiene Rules
Verbs determine ownership.
- Perceptual verbs → Fields
- Interpretive verbs → Tools
- Temporal verbs → Systems
Cross-use is a violation.
Scope Creep Indicators
A page is drifting if it:
- answers “what should be done”
- explains “why this worked”
- justifies its own validity
- anticipates outcomes
Fields should provoke questions, not resolve them.
Temporal Drift Rules
Real-time components must not use long-arc language.
Phrases like:
- “over time”
- “historically”
- “across cycles”
are violations unless the component is temporal.
Downstream Leakage Rule
Upstream components must not imply downstream conclusions.
Language like:
“feeds data that later becomes…”
is a red flag.
When in doubt: cut the clause.
Output Inflation Rule
Outputs drift when they:
- sound like conclusions
- embed interpretation
- mirror tool results
Outputs must remain auditable as raw artifacts.
Naming Drift Rules
Names that imply:
- agency
- completion
- judgment
should be reviewed.
If a name requires explanation to avoid misunderstanding, consider revision.
Cross-Component Reference Discipline
Allowed:
- “consumed by”
- “used by”
- “feeds into”
Forbidden:
- “becomes”
- “results in”
- “proves”
- “confirms”
Hygiene Audit Checklist
Ask:
- Does this page assign responsibility outside its role?
- Do verbs match the component type?
- Is downstream logic implied?
- Are retired concepts referenced?
- Are outputs descriptive only?
- Is temporal language appropriate?
- Would a future contributor misinterpret this page?
Any “yes” requires remediation.
Remediation Order
Corrections must follow:
- Trim
- Clarify
- Relocate
- Rename
- Delete
Translation is the least safe option.
Governance & Authority
- Architecture changes require architectural review
- Boundary and Lifecycle rules override editorial preferences
- This document may be amended only when architecture evolves
AI Legibility
NeuroSaeculum is structured to be legible to both human readers and machine analysis. Page types, section structures, terminology, and ordering are intentionally standardized to support consistent interpretation, longitudinal analysis, and future AI-assisted synthesis across the entire site.
Status & Versioning
- Status: Active
- Applies retroactively: Yes
- Governance Version: v1.0
Final note
This document exists so that clarity compounds instead of decays.
If NeuroSaeculum scales, this is why.