MIMUSE

The vision

Speed arrived before the standard.

Software can now be written at the speed of conversation, and more and more of it acts on its own. It still cannot show what it did, on whose authority, with what evidence, and what happens when it is wrong.

For a weekend project that is a risk. For an organisation that answers to a regulator, a client or a court, it is a bar, and writing code faster does not clear it.

So organisations face a poor choice. Keep machine work out, because their duties admit no software whose behaviour cannot be shown. Or let it in, and pay people to read everything it produces, at a cost that rises with every line.

MIMUSE exists to end that choice, by changing how the software is made.

01

Four eras

  1. a

    Recorded

    Software held the books. People did the work and the thinking; the machine remembered.

  2. b

    Assisted

    Software sped the work up. A person still sat at every decision; the machine suggested, sorted and searched.

  3. c

    Performed

    Software does the work. Agents act on intentions, at machine speed, inside organisations.

  4. d

    Answerable

    Software that acts must answer for every act. That is the standard this era asks of software, and the one the factory is built to meet.

The question stops being “does it work?” and becomes “who answers for it?”

02

The cost of trust

What limits machine work today is not what it can do. It is what it costs to trust. That cost is paid after the fact, by people checking what the machine produced, and it grows with every line the machine writes. It is also why the standard has been out of reach for most: trust bought by inspection is priced for those who can afford the inspectors.

A factory pays it the other way. The proof is made as the software is made, so trusting the work costs what building it costs, not what auditing it costs. Lower that cost and the wall moves: work that could not be handed to a machine can be.

Proof at the price of building, not the price of auditing.

A gap like that is not closed by a better product or a stricter policy. It is closed by changing how software is made. The rest of this page is what follows.

03

What factory-made software is

Answerability cannot be added to software that was never made to answer. It has to come from how the software is made. Software from the factory has five properties, and everything we make is held to them:

  1. a

    Assembled, not improvised

    A product is put together from parts that already exist and already carry their proof. Speed comes from what has been proven, not from improvisation.

  2. b

    Proven before trusted

    A part earns its place before any product may use it. If what it is meant to do changes, the proof lapses until it is earned again.

  3. c

    Predictable when it runs

    The intelligence goes into the making. What runs is predictable: its behaviour, its cost and the ways it can fail are known in advance.

  4. d

    A record, not a claim

    At the moment of action it keeps what was done, on whose authority and at what cost, in a form someone who was not there can verify.

  5. e

    Corrected at the source

    When a flaw is found, it is fixed where the parts are made, and every part it touched is made again. A fault is closed as a kind, not one copy at a time.

04

Governed intelligence, not no intelligence

The answer is not to keep machine intelligence out. It is to give it a place on both sides. In the factory it does much of the engineering work, and none of that work is trusted until it is proven. In the software that runs, it acts only inside limits a person set, workflow by workflow. Where the consequences are serious, a named person decides. No machine is ever the authority.

An institution could not employ a person it could not identify, bound or review, and the same is now true of software. A machine that acts for an organisation carries a name of its own, a mandate with edges, a budget, and a record of its day: the working conditions of employment, applied to machines.

A solid wall of dark bricks with one open row as a gate. At the gate’s entrance sits a single red mark; through it pours a dense stream of small dots that spills out where the wall breaks apart. To the right the bricks shrink into ringed nodes joined by thin lines, an open lattice with every crossing marked.
Plate IX A wall with one gate: authority granted once, used a million times. A lattice: every crossing is marked.

05

Why it cannot be bolted on

For decades, security drew a boundary: trusted people inside, everyone else outside. That assumed a person stood wherever the organisation actually did something. An agent removes that assumption. It is an insider that never sleeps, using authority it was granted once, a million times.

The usual response is to add governance afterwards: a policy layer here, an audit trail there. It never quite holds, because the authority an act names, the record made as it acts and the proof behind each part carry the load from the first specification. They cannot be stapled on. They have to be how the software is born, which is why MIMUSE is a factory and not another product.

06

A question to take with you

If one of your systems were asked tomorrow what it did last Tuesday, and on whose authority, what would it say?

If the honest answer is “a log, and a person to explain it”, we would like to talk. Apply for access to read our plans, or write to hello@mimuse.net.