Sophia & Nomos Parity Feature Handbook (INT-342)#

1. Introduction#

The Sophia & Nomos ecosystem is built on a strict Two-Plane Open-Core Architecture (Law 1: Dual-Core Inversion Law). The system separates high-level architectural design and cognitive intent (the Intent Plane governed by Sophia) from strict mathematical, AST-proven code execution (the Substrate Plane governed by Nomos).

A critical element of this architecture is Bilateral Twin Parity, which operates strictly within physical and temporal boundaries defined mathematically by our Markov Blanket Boundary Invariant (ADR-0033: Markov Blanket Boundary Invariant).

2. Bilateral Twin Parity#

For every executable change to the system, there must exist two distinct tasks in the Living Ledger:

1. The Intent Task (INT-*): Contains the Single Source of Truth (SSoT) specifications, motivation, acceptance criteria, and architectural maps. Written by Sophia or the human architect.
2. The Substrate Task (SUB-*): Contains the algorithmic scope, DTO structs, deterministic invariants, and test matrices. Written by Nomos.

These tasks are Twins. They must reference each other. No Substrate task can be merged to main without its Intent twin fully realized, and no Intent specification is complete until its Substrate twin enforces it via AST.

3. Parity Validation Gates#

The nomos command-line tool mathematically enforces this parity during execution:

3.1 Traceability Gate#

When nomos task sync is invoked on a Substrate task, the 12-Gate Definition of Done (DoD) pipeline scans the Go source code.

1. It identifies all // @intent INT-XXX metadata tags in the code.
2. It cross-references these tags against the Living Ledger.
3. If the associated INT-XXX task does not exist, or the Living Vault SSoT file is missing/incomplete, the compilation fails with an exact error.

3.2 Feature Flags & Overrides#

In extreme circumstances (e.g. staging server crashes requiring an emergency patch), developers can invoke --drift to temporarily bypass the Traceability Gate. When --drift is used, the system automatically mints a new Drift Resolution Task in the Ledger, ensuring the cognitive debt is formally tracked and resolved in a subsequent sprint.

4. The SSoT and Living Vault#

The intent/ repository directory represents the Living Vault. It contains Markdown documents acting as executable specifications.

• Law 4: "Every contract, schema, and configuration possesses exactly one compiled Go SSoT with byte parity."
• If the Markdown SSoT is updated, the associated Substrate Go code must be mathematically aligned, otherwise the ecosystem drift alarms will fail CI/CD pipelines.

5. UI Dashboards#

Our Public Portals (e.g., sophialabs.ca) contain real-time Parity Dashboards that render the current alignment between the Intent Plane and the Substrate Plane. This live telemetry ensures complete transparency over the architectural health of the ecosystem.