Skip to content

System Architecture (v0.1) ​

1. Architectural Objectives ​

A compliant RIGOR implementation MUST:

  1. Be fully deterministic
  2. Isolate processing stages
  3. Operate on a Canonical Graph
  4. Support diff and evolution workflows
  5. Be testable at module level
  6. Maintain stable contracts between engines

The architecture MUST prevent cross-layer implicit dependencies.


2. High-Level System Architecture ​

The system is composed of independent engines organized in a layered pipeline.

text
                    ┌──────────────────────┐
                    │     CLI Interface     │
                    └──────────┬───────────┘
                               │
                    ┌──────────▼───────────┐
                    │    Application API    │
                    └──────────┬───────────┘
                               │
  ┌─────────────────────────────────────────────────────────┐
  │                    Core Processing                        │
  │                                                          │
  │  Parser → Graph Builder → Canonicalization → Validation │
  │                                   │                      │
  │                                   ▼                      │
  │                    Diff → Versioning → Migration         │
  └─────────────────────────────────────────────────────────┘

Each module MUST expose explicit inputs and outputs.


3. Module Decomposition ​

The architecture consists of 13 logical modules.

3.1 Parser & Loader ​

Responsibility:

  • Parse YAML
  • Validate syntax
  • Normalize basic structures
  • Detect early structural violations

Input: Raw YAML text

Output: Parsed intermediate representation (IR)

Constraints:

  • No semantic validation
  • No graph construction
  • No mutation of input data

3.2 Canonical Graph Builder ​

Responsibility:

  • Transform IR into Canonical Graph
  • Resolve references
  • Enforce identity uniqueness
  • Construct node and edge structures

Input: Parsed IR

Output: Canonical Graph

Constraints:

  • Deterministic ordering
  • Immutable node construction
  • No validation side-effects

3.3 Canonicalization Engine ​

Responsibility:

  • Normalize ordering
  • Remove irrelevant noise
  • Produce stable structure
  • Compute structural hash (optional)

Input: Canonical Graph

Output: Canonical Graph (normalized)

Guarantees: Two semantically equivalent specs MUST produce identical canonical representations.

3.4 Validation Engine ​

Responsibility:

  • Structural validation
  • Semantic validation
  • Process validation
  • Event validation
  • Version validation

Input: Canonical Graph

Output: Validation Report

Constraints:

  • Must not mutate graph
  • Must accumulate errors deterministically
  • Must not perform diff logic

3.5 Constraint Engine ​

Responsibility:

  • Evaluate declared constraints
  • Compose constraints
  • Short-circuit when required
  • Produce structured violations

Input: Canonical Graph, Validation context

Output: Constraint violations

3.6 Diff Engine ​

Responsibility:

  • Compare two Canonical Graphs
  • Detect structural differences
  • Generate ChangeSet
  • Classify changes

Input: Old Canonical Graph, New Canonical Graph

Output: Deterministic ChangeSet

Guarantees: Identical inputs MUST produce identical ChangeSets.

3.7 Versioning Engine ​

Responsibility:

  • Analyze ChangeSet
  • Determine breaking changes
  • Validate semantic version compliance
  • Enforce bump rules

Input: ChangeSet, Declared versions

Output: Version validation result

3.8 Migration Engine ​

Responsibility:

  • Apply ChangeSet
  • Transform Canonical Graph
  • Validate result
  • Ensure idempotence

Input: Canonical Graph, ChangeSet

Output: New Canonical Graph

3.9 Event Resolution Engine ​

Responsibility:

  • Validate event declarations
  • Validate event payload types
  • Link events to transitions
  • Ensure cross-spec coherence

Input: Canonical Graph

Output: Event validation result

3.10 Error Model ​

Responsibility:

  • Define error structure
  • Guarantee stable error codes
  • Provide serialization formats
  • Maintain deterministic ordering

Output: Structured error objects

3.11 Application API ​

Responsibility:

  • Expose programmatic interface
  • Orchestrate engines
  • Provide stable integration layer

This API MUST:

  • Be stateless
  • Accept explicit inputs
  • Return structured outputs

3.12 CLI Interface ​

Responsibility:

  • Parse CLI arguments
  • Invoke Application API
  • Format output
  • Set exit codes

CLI MUST NOT:

  • Contain business logic
  • Implement validation rules
  • Implement diff logic

3.13 Performance & Testing Layer ​

Responsibility:

  • Enforce complexity limits
  • Define performance benchmarks
  • Provide regression testing hooks
  • Validate determinism

4. Data Flow Contracts ​

Each engine MUST respect strict data contracts.

4.1 Canonical Graph Contract ​

The Canonical Graph MUST:

  • Be immutable
  • Have stable node IDs
  • Provide canonical paths
  • Expose deterministic iteration order

No engine may rely on YAML ordering.

4.2 ChangeSet Contract ​

ChangeSet MUST:

  • Contain ordered atomic changes
  • Classify each change
  • Include canonical paths
  • Be reproducible

4.3 Validation Report Contract ​

Validation Report MUST:

  • Include ordered error list
  • Include severity
  • Include canonical path
  • Include error code
  • Be serializable to JSON

5. Engine Interaction Rules ​

Allowed interactions:

  • Parser → Graph Builder
  • Graph Builder → Canonicalization
  • Canonicalization → Validation
  • Validation → CLI
  • Canonicalization → Diff
  • Diff → Versioning
  • Diff → Migration

Forbidden interactions:

  • CLI directly mutating Graph
  • Validation invoking Diff implicitly
  • Migration modifying original Graph instance
  • Diff reading raw YAML

6. Deterministic Ordering Requirements ​

The system MUST ensure deterministic ordering for:

  • Entities
  • Properties
  • Processes
  • States
  • Transitions
  • Events
  • Errors
  • ChangeSet entries

Ordering MUST be lexicographically stable unless otherwise defined.


7. Concurrency Model ​

Unless explicitly implemented:

  • The engine SHOULD operate single-threaded.
  • Parallelization MUST NOT break determinism.
  • Shared mutable state is prohibited.

8. Extensibility Boundaries ​

Extensions MAY include:

  • New validation rules
  • New constraint types
  • New artifact generators
  • New CLI commands

Extensions MUST NOT:

  • Alter Canonical Graph semantics
  • Modify existing error codes
  • Change diff classification rules

9. Non-Goals ​

The architecture does NOT define:

  • Persistence implementation
  • Runtime execution of business logic
  • Database schema generation
  • Deployment strategy

These are external to the RIGOR engine.


10. Compliance Requirements ​

An implementation is compliant if:

  1. All modules exist logically (even if combined physically)
  2. Data contracts are respected
  3. Determinism is guaranteed
  4. Canonical Graph is immutable
  5. Diff and Versioning integrate correctly

Physical code organization MAY vary, but logical separation MUST exist.


11. Summary ​

The RIGOR architecture is:

  • Layered
  • Deterministic
  • Graph-centered
  • Evolution-aware
  • Strictly modular

Subsequent documents define each module in technical depth.

AI Constraint Protocol