IronTrex Steelmatter Systems

Open-source execution authority for AI agents.

Steelmatter binds machine actions to explicit mandates, exact-action permits and shared spending allowances. R1 implements protected purchase-order execution for Odoo 18: authorise the precise purchase, preserve its budget while the outcome is uncertain, and reconcile destination evidence before settlement.

The execution path protects supplier, delivery, quantity, unit and tax details; rejects stale approvals and changed actions; and uses stable operation references to prevent duplicate purchases within the supported Odoo integration. Recovery anchoring detects restored state and keeps new writes fenced until reconciliation passes. Signed execution and observation records can be verified offline.

Verified results

The 31 October 2026 main-branch CI run passed on source commit f8b6ebe26c845c4990959b7abbeec8ae58345dd9:

Coverage includes concurrent budget contention, replay and tampering, process crashes, lost responses, approval drift, destination changes and restore recovery. These are correctness and recovery results. See validation evidence and measurement scope for the test breakdown, reproducible entry points and performance limits.

Deployment scope

The Apache-2.0 R1 engine authorises Odoo 18 purchase orders, enforces spending limits and reconciles orders after interrupted execution. Contact IronTrex Commercial for enterprise connectors, session controls, support SLAs and managed VPC or on-premises deployment options.

The R1 sandbox uses synthetic data on isolated infrastructure with one tenant, one Odoo company and one active backend. Amounts are recorded in integer paise (INR). Start external integration evaluation in observe-only mode. See R1 configuration and security controls and release notes.

The local quickstart uses the R0 synthetic destination. The R1 sandbox exercises external Odoo execution separately. MCP purchase creation remains outside R1 scope.

The service is written in Go (ADR-001). Start with the synthetic quickstart, then follow its R1 sandbox section. Read the R1 decisions and limits and recovery procedures before evaluating external execution.

Status

• Contracts: docs/contracts/I02-contract.md covers strict JSON input, payload validation, RFC 8785 digests, SM-JWS-ES256-1 signing, Go/TypeScript golden vectors, the closed OpenAPI spec and the PostgreSQL locking prototype.
• I03–I06 core transactions: transactional budget accounting, exact-action admission and crash recovery; see docs/engine.md. The R0 baseline includes 40 integration scenarios covering T01–T16, T20, T22, T23, T27, T28 and T39–T41, including real process-crash tests. The active R1 gate extends this baseline.
• I07 evidence: read-only observer, signed execution and observation records, evidence export and reconcile, and the standalone TypeScript verifier and CLI; see docs/evidence.md.
• I08 demo: scripts/demo runs the flagship, stale-supplier, lost-response and agent-injection scenarios from a clean state; see docs/quickstart.md. scripts/ci also writes the 31-case day-4 report to .out/sprint-day4-report.md.
• SDK: packages/sdk is a typed client for the R0 and R1 HTTP APIs, with timeouts and contract-aware retries; see packages/sdk/README.md.
• MCP adapter: adapters/mcp is a thin stdio MCP server forwarding authenticated calls through the SDK; the service enforces assigned-actor execution and ADR-002 read access; see adapters/mcp/README.md.
• Browser demo: implemented as recorded playback with browser-side evidence verification; see demo/README.md.
• Acceptance reporting: the active r1-engine gate is defined in ci/required.json. It requires 527 test identities across seven phases. The separate real-Odoo gate runs external execution and recovery scenarios. Required identities, executed assertions and independent QA cases are different counts; report them separately.
• Distribution: Apache-2.0 source. TypeScript packages are included in the repository and remain private: true rather than published npm packages. See RELEASE_NOTES.md for the supported scope.

Requirements

Pinned in versions.env: Go 1.27.3, PostgreSQL 17.10, Node 26.11.0. Library pins are in go.mod and packages/verifier/package-lock.json.

Quick start

Full walkthrough: docs/quickstart.md.

export STEELMATTER_ADMIN_URL='postgres://USER@localhost:5432/postgres?sslmode=disable'
scripts/bootstrap                       # verify tools, modules; generate synthetic keys
(cd packages/verifier && npm ci --ignore-scripts)
DEMO_SCENARIO=flagship scripts/demo      # protected synthetic action and offline evidence verification
export STEELMATTER_TEST_ADMIN_URL="$STEELMATTER_ADMIN_URL"
scripts/ci                              # all test phases, aggregate gate and acceptance report

No local PostgreSQL? With Docker running, scripts/dev-postgres starts the pinned image and prints the URL to export.

The admin URL needs CREATEDB and CREATEROLE. Each integration test creates its own database (sm_test_<random>) plus executor and observer login roles, then drops them. Set STEELMATTER_TEST_KEEP_DB=1 to keep the database for inspection.

Commands

CI gate

steelmatter-ci is the single required check. ci/required.json defines the stages:

• I01: foundation.
• I02: contracts.
• I03-I06: core transactions.
• I07: evidence.
• I08: the 340-check implementation baseline.
• sprint-day4: the 31-case checkpoint.
• full-R0: the retained R0 acceptance stage.
• r1-engine: the active stage, including R1 execution, recovery and demo provenance checks.

The gate fails when a required phase is missing, any test fails, is skipped or doesn't finish, a required test is absent, or a required case is not PASS. Every one of the 44 catalogue cases appears in the report. A case is PASS only when its mapping is marked complete and every mapped test passed.

Layout

cmd/                 steelmatter (service), smkeys (synthetic keys), smci (CI gate), smvectors (golden vectors)
core/                engine packages: contract (parser, payloads, canonical, JWS), db (roles, migrations),
                     dbtest (harness), keys (trust store), httpapi (error catalogue), server
api/                 openapi.yaml (closed OpenAPI 3.1) and its consistency tests
schemas/             the five payload JSON Schemas (packet, unchanged)
packages/verifier/   standalone TypeScript verifier (@irontrex/steelmatter-verifier, private)
packages/sdk/        typed TypeScript API client (@irontrex/steelmatter-sdk, private); see its README
adapters/mcp/        thin MCP adapter for an actor agent over stdio (@irontrex/steelmatter-mcp, private)
fixtures/            packet examples and golden vectors
prototypes/locking/  I02 locking prototype (PROTOTYPE, not product)
tests/conformance/   cross-language conformance suite
tools/ciagg          aggregate gate logic
ci/                  required results per stage, acceptance catalogue
scripts/             entry points
docs/                public technical docs, ADRs and contracts

Licence

Steelmatter is distributed under the unmodified Apache License 2.0, NOTICE and third-party notices. Names and marks are governed by Apache-2.0 section 6.