autoTMR

Automate software component generation with diversity to reduce common-cause failures.

Inspired by Triple Modular Redundancy (TMR), autoTMR guides you to build multiple independent implementations of each component — differing in libraries, algorithms, and design patterns — then verifies they behave identically under nominal conditions via shared contract tests.

Why autoTMR?

When redundant components share the same implementation, they fail together (common-cause failure). autoTMR enforces intentional diversity across versions while contract tests guarantee behavioral equivalence for valid inputs.

Workflow

flowchart TD
    subgraph intake [Phase 1: Intake]
        SystemSpec[spec/system.md]
        Questions[Agent asks clarifying questions]
        Manifest[autotmr.yaml]
    end

    subgraph decompose [Phase 2: Decompose]
        HLD[design/system-design.md]
        ComponentTree[components/ hierarchy]
        CompSpec[spec.md per component]
    end

    subgraph diversify [Phase 3: Diversify]
        DivMatrix[diversity-matrix.md]
        Versions[versions/v1..vN]
    end

    subgraph verify [Phase 4: Verify]
        Contract[tests/contract.yaml]
        Runners[Per-version test runners]
        Report[Equivalence report]
    end

    subgraph fuse [Phase 5: Fuse]
        InvokeConfig[interface.invoke + run.sh]
        FusionRuntime[autotmr invoke]
        FusionTest[autotmr fusion-test]
    end

    SystemSpec --> Questions --> Manifest
    Manifest --> HLD --> ComponentTree --> CompSpec
    CompSpec --> DivMatrix --> Versions
    Versions --> Contract --> Runners --> Report
    Report --> InvokeConfig --> FusionRuntime --> FusionTest

Loading

Quick Start

1. Install the CLI

pip install -e ".[dev]"

2. Initialize a project

autotmr init --spec spec/system.md

Or start from the included example:

cd examples/token-validator
autotmr status
autotmr validate

3. Run the Cursor workflow

In Cursor, invoke the orchestrator skill:

@autotmr-orchestrate

The agent routes through phase skills:

Skill	Phase
autotmr-intake	Refine system spec, scaffold project
autotmr-decompose	High-level design + component tree
autotmr-design	Component-level design documents
autotmr-diversify	N diverse implementations per leaf
autotmr-verify	Contract tests + per-version equivalence
autotmr-fuse	Fusion voting/checking runtime

4. Validate and fuse

autotmr validate
autotmr status
autotmr invoke --component token-validator/parser --inputs '{"token":"eyJhbGci.a.b"}'
autotmr fusion-test --component token-validator/parser

Project Layout

<your-project>/
├── autotmr.yaml                 # manifest (diversity_count defaults + overrides)
├── spec/system.md               # system functional requirements
├── design/system-design.md      # high-level design
├── components/
│   └── <component-id>/
│       ├── spec.md              # functional spec, inputs, outputs
│       ├── design.md            # component design (optional)
│       ├── diversity-matrix.md  # library / algorithm / design axes
│       ├── versions/
│       │   ├── v1/              # implementation + run.sh + README
│       │   ├── v2/
│       │   └── vN/
│       └── tests/
│           ├── contract.yaml    # portable I/O test vectors
│           └── README.md        # how to run tests per version
└── .cursor/skills/              # autoTMR skills (from this repo)

Core Concepts

Language-agnostic

Specs, contracts, and skills are not tied to a programming language. Each version README documents build/run for the chosen language.

Configurable diversity

Default 3 versions per leaf (classic TMR). Override per component in autotmr.yaml:

version: "1"
defaults:
  diversity_count: 3
components:
  token-validator/signature-checker:
    diversity_count: 2
    interface:
      type: cli
      inputs: [token, secret]
      outputs: [valid, error]

Diversity matrix

Each version must differ on at least one axis:

1. Library stack — different libraries or stdlib-only vs third-party
2. Algorithm — different approach to the same problem
3. Design pattern — procedural vs functional vs state machine, etc.

No two versions may share the same (library + algorithm + design) triple without documented justification.

Contract tests

Shared YAML test vectors define inputs and expected outputs. All versions must pass every nominal case:

component: my/component
cases:
  - name: nominal
    inputs:
      field_a: "value"
    expected_outputs:
      result: true

Fusion runtime

After per-version equivalence is verified, configure fusion in autotmr.yaml and add run.sh per version.

diversity_count	Mode	Rule
2	compare	Both replicas must agree (dual-modular redundancy)
3+	vote	Majority quorum wins (classic TMR)

Disagreement policies (per component):

• fault (default) — return error on mismatch or no quorum
• use_primary — fall back to v1 output with warning (exit code still 1)

defaults:
  fusion:
    disagreement: fault
    timeout_seconds: 30
components:
  my/component:
    interface:
      type: cli
      invoke:
        template: "components/my/component/versions/{version}/run.sh"
        args:
          field_a: --field-a

CLI Reference

Command	Description
autotmr init [--spec PATH]	Scaffold a new project from templates
autotmr validate [ROOT]	Validate manifest, structure, and schemas
autotmr status [ROOT]	Show current phase and component summary
autotmr invoke --component ID --inputs JSON	Invoke all replicas and fuse outputs
autotmr fusion-test --component ID	Run contract cases through fusion layer

Example

See examples/token-validator/ for a complete demo:

• System: JWT-like token parser + signature checker
• parser: 3 diverse versions
• signature-checker: 2 diverse versions
• Contract tests for each leaf

autotmr validate -C examples/token-validator
autotmr fusion-test -C examples/token-validator --component token-validator/parser

Skills Location

Project skills live in .cursor/skills/. Copy or symlink this directory into your target project, or work directly from this repo.

Out of Scope (v1)

• HTTP / in-process module invocation for fusion
• Byzantine fault tolerance beyond output comparison
• Composite pipeline orchestration (fuse leaf-by-leaf only)
• Language-specific code generators
• CI/CD templates (documented as optional in verify skill)

Development

pip install -e ".[dev]"
pytest
ruff check src tests

License

MIT