Concepts, built
far enough to
prove they work.

Project 01 · in development

SMIR & SMIRE

An intermediate representation for generated code.

Code is written by models faster than anyone can review it, in a dozen languages, and plausible is not the same as correct. SMIR is one explicit, language-agnostic representation of what a program actually does — control flow, state, I/O and types — and SMIRE is the engine that parses generated code into it, checks it, runs it, and only then hands it back. From AI-generated to verified.

// a function, as SMIR sees it
{
  "smir_version": "0.1.0",
  "functions": [{
    "name": "add_one",
    "params": [{ "name": "n", "type": "int" }],
    "cfg": {
      "entry": "block_0",
      "blocks": [{
        "id": "block_0",
        "statements": [{ "kind": "assign", … }],
        "terminator": { "kind": "return", … }
      }]
    },
    "io": { "rows": [], "conflicts": [] }
  }]
}

How it fits together

SMIRE owns the loop: it parses incoming code into SMIR, checks it, runs it, and hands code back out. StateMind sits outside that loop — it proposes, the engine decides.

• SMIRE is everything inside the frame: parsing, the SMIR document, validation, the sandboxed run, the deterministic fix and refactor passes, and code generation.
• StateMind is only consulted when the deterministic passes run out of ideas. Its proposal has to keep the functions and classes it was given, compile, and behave — otherwise SMIRE throws it away and keeps the original.

What SMIR makes explicit

• Control flow. Every function becomes a graph of basic blocks with a single terminator: jump, branch, loop or return. Nothing implied by indentation.
• Intent that survives a rewrite. SMIR records what the code was supposed to be, so a suggestion that quietly drops the functions it was given is rejected, not merged.
• State and I/O. Step machines, transitions and a cross-reference of every signal read and written — which makes conflicting writes and dead outputs findable instead of debatable.
• A checked round-trip. Code is parsed into SMIR and generated back, then compiled and executed. If the behaviour differs, the representation is wrong — not the code.

SMIR v0.1 is running: the engine parses, validates, repairs and executes, and the narrow model that proposes those repairs is trained in-house and stays on-premise.

Project 02 · working prototype

Tide

An AI command center for maritime risk.

One screen that follows a fleet of 475 ships from publicly available data, quantifies the risk of every voyage and gives a reasoned recommendation — including what diverting costs against what staying the course costs. Most tracking tools show you where a ship is. Tide answers the question that actually costs money: is diverting cheaper than sailing on?

Under the hood

• Real AIS positions from an external provider, with honest provenance: the status bar names the source, how many ships are fresh and how old the oldest fix is. Nothing is called realtime that is not.
• A risk model that combines weather, geopolitics and news, port congestion and chokepoints, with exponential decay on the age of every observation — a day-old storm report should not weigh as much as an hour-old one.
• Prediction and route comparison: a PyTorch delay model plus a Monte-Carlo comparison of alternatives on fuel, emissions, charter cost and delay cost. The compute picks CUDA on a GPU box and falls back to CPU.
• Accountability: predicted versus actual ETAs are kept, along with how often a recommendation was followed and how much delay that avoided. The model is judged on its own track record.
• Explainability: every score shows how it was built up, every recommendation shows its assumptions — the minimum for use in operations and compliance.

A day of delay on a container ship costs tens of thousands in charter, fuel and contract penalties. The value is not the map; it is the answer underneath it, with the uncertainty attached and a record of whether the answer turned out to be right.