Skip to content

RIGOR

Implementation

CLI & Execution Model (Normative – v0.1)

Status: Normative Scope: Defines the command-line interface behavior, execution pipeline, orchestration rules, exit codes, and determinism guarantees of the RIGOR toolchain.

This document formalizes how all engines are invoked and composed in a compliant implementation.


1. Purpose

The CLI & Execution Model defines:

  • Command structure
  • Execution pipeline order
  • Engine orchestration
  • Output formats
  • Exit codes
  • Determinism guarantees
  • Error handling model

It is the integration layer between all normative engines.


2. Execution Pipeline Overview

The canonical execution pipeline MUST be:

  1. Parser & Loader
  2. Canonical Graph Builder
  3. Canonicalization Engine
  4. Validation Engine
  5. Diff Engine (if previous version provided)
  6. Versioning Engine (if diff executed)
  7. Migration Engine (if migration requested)
  8. Event Resolution Engine
  9. Output Rendering

Each step MUST execute in the defined order.


3. CLI Command Model

The CLI MUST expose deterministic commands.

Minimum required commands:

  • rigor validate
  • rigor diff
  • rigor version
  • rigor migrate
  • rigor resolve-events

Optional commands MAY exist but MUST NOT alter core behavior.


4. Command Definitions

4.1 Validate

rigor validate <spec-file> [--strict] [--json]

Execution:

  • Parse
  • Build graph
  • Canonicalize
  • Validate
  • Resolve events

Exit codes:

  • 0 → valid
  • 1 → validation errors
  • 1 → internal failure


4.2 Diff

rigor diff <previous-spec> <current-spec> [--json]

Execution:

  • Parse both
  • Build both graphs
  • Canonicalize both
  • Compute ChangeSet
  • Output ChangeSet

Exit codes:

  • 0 → no change
  • 2 → changes detected
  • 2 → internal failure


4.3 Version

rigor version <previous-spec> <current-spec> [--json]

Execution:

  • Parse both
  • Canonicalize
  • Diff
  • Evaluate version

Exit codes:

  • 0 → valid version
  • 3 → version violation
  • 3 → internal failure


4.4 Migrate

rigor migrate <previous-spec> <current-spec> <migration-file> [--json]

Execution:

  • Parse both
  • Canonicalize
  • Diff
  • Version evaluation
  • Apply migration
  • Validate migrated graph
  • Resolve events

Exit codes:

  • 0 → success
  • 4 → migration failure
  • 4 → internal failure


4.5 Resolve Events

rigor resolve-events <spec-file> [--json]

Execution:

  • Parse
  • Canonicalize
  • Resolve events

Exit codes:

  • 0 → valid
  • 5 → resolution errors
  • 5 → internal failure


5. Determinism Requirements

The CLI MUST guarantee:

  • Stable ordering of outputs
  • Stable JSON structure
  • No timestamp injection (unless explicitly requested)
  • No non-deterministic logging

Identical inputs MUST produce identical outputs.


6. Output Formats

The CLI MUST support:

  • Human-readable text (default)
  • JSON (--json flag)

JSON output MUST:

  • Exactly serialize engine output contracts
  • Preserve ordering defined in normative documents
  • Use stable key ordering

No additional keys allowed.


7. Error Handling Model

Errors are categorized as:

  • Validation errors
  • Version violations
  • Migration failures
  • Internal engine failures

Internal failures MUST:

  • Produce non-zero exit > 10
  • Output structured error object (if JSON mode)

8. Logging Model

Logging MUST be optional.

Flags MAY include:

  • --verbose
  • --debug

Logs MUST NOT alter behavior or output structure.


9. Configuration Model

CLI MAY accept configuration file:

RigorConfig {
    validationMode: "strict" | "non-strict"
    versionPolicy: object
    outputFormat: "text" | "json"
}

CLI flags MUST override config file.


10. Streaming & Large Files

Implementation MAY support streaming parsing.

However:

  • Canonical Graph MUST be fully constructed before diff/validation.
  • Partial validation is not allowed in normative mode.

11. Execution Isolation

Each CLI invocation MUST:

  • Be stateless
  • Not cache previous runs (unless deterministic cache)
  • Not modify input files

Temporary files MUST be cleaned deterministically.


12. Parallel Execution

Parallelization MAY be used internally if:

  • It does not alter output order
  • It preserves determinism

Rule execution parallelization MUST preserve ordered aggregation.


13. Stability Guarantees

Breaking changes in:

  • CLI flags
  • Exit codes
  • JSON schema

MUST require major version increment of RIGOR.


14. Non-Goals

The CLI does NOT:

  • Provide runtime execution environment
  • Integrate with external systems
  • Provide interactive UI
  • Auto-fix errors

It is a deterministic orchestration interface.


15. Compliance Criteria

An implementation is compliant if:

  • It executes engines in defined order
  • It enforces exit codes precisely
  • It guarantees deterministic output
  • It respects JSON schema contracts
  • It isolates execution per invocation

16. Execution Model Summary

The CLI & Execution Model:

  • Orchestrates all engines
  • Defines deterministic execution flow
  • Guarantees stable output
  • Enforces strict exit code discipline
  • Ensures composability of the toolchain

At this stage, the full RIGOR implementation architecture includes:

  1. Parser & Loader
  2. Canonical Graph Builder
  3. Canonicalization Engine
  4. Validation Engine
  5. Diff Engine
  6. Versioning Engine
  7. Migration Engine
  8. Event Resolution Engine
  9. CLI & Execution Model

The implementation layer is now structurally complete under normative definition.

AI Constraint Protocol