Workshop plan for OSFF New York: intent → specification → verified model → working system

[AttilaMihaly]

The problem the room already has

Everyone can now generate working code from a description. Nobody can tell whether the result is
what the business asked for. Review does not scale to the volume AI produces, and reviewing
AI-written code with another AI is not a trust story anyone in finance will sign.

What we offer

1. The domain expert never leaves the loop. They state the problem, they read the specification,
they verify the behavior. There is no handoff where the requirement is translated by someone who
does not own it.

2. The specification is the source of truth, and a human can read it. Markdown with YAML front
matter — diffable, reviewable, versioned. When the rule changes you change the spec and regenerate,
not patch the code.

3. Correctness is checked three ways before any system exists. The compiler catches what does
not hold together. Generated test cases catch what compiles but computes the wrong answer. Visual
verification catches the one thing neither can — a correct implementation of the wrong requirement.

4. The business logic is compiled, not written. The AI is not allowed to author the rules; a
Morphir code generator emits them, deterministically, from a model that passed all three checks.
The AI's freedom is spent where it is actually worth having — wiring the logic into whatever stack
you already run.

That is the takeaway: deterministic core, flexible shell. The rules come out identical every
time and on every target; the shell bends to the technology you have. And nothing is traded away
for that — generating from the IR is faster than having a model write the logic, not slower.

5. The loop closes: production tells you what the spec missed. (stretch — see below) Because
the logic is a model rather than opaque code, you can run it back over real data and see which
branches actually fire. The catch-all case turns out to hold three real scenarios nobody had named.
That is a new requirement, discovered from evidence, and it goes back into the specification at
step 2.

The narrative that carries it

#	On screen	The point being made
1	User describes a business problem in chat	Intent, in the expert's own words — imprecise by nature
2	It becomes a Markdown + YAML spec (Substrate)	Value 1, 2 — intent becomes a durable, readable contract
3	MCP tools build the model; it compiles to Morphir IR	Value 3, first rung — errors that never reach the user
4	The LLM writes test cases through the same tools	Value 3, second rung
5	morphir develop visualizes it; the user clicks through the cases	Value 3, third rung — and value 1, the expert signs off
6	The LLM assembles a running system using Morphir's generators	Value 4 — the payoff
7	(stretch) Replay the logic over production data; the catch-all branch splits	Value 5 — the loop closes back to step 2

Each beat earns one claim. Everything else is detail we cut.

On step 7

Suppose the system from step 6 has been running for a while and there is real data behind it. We
point the same verified logic at that history and ask which branches fired and what landed in the
catch-all. Some of what is sitting in that bucket is not noise — it is a distinction the business
makes but never wrote down. We name it, add it to the spec, and run the whole pipeline again.

This is the moment where the model stops being a build-time artifact and becomes an instrument for
understanding the business. It is also cheap to make credible: the language is constrained enough
that running the logic over a large dataset is safe by construction.

Marking it as a stretch goal — it is the most impactful beat and the least built. If it does not
come together in time it is cut cleanly, since steps 1–6 stand on their own.

What's new since London

London was steps 1, 3, 4 and 5, and it stopped at the visualization. New York adds the ends: the
specification in front, so intent is an artifact rather than a transcript; the generated system
behind, so the audience sees where it lands; and — if we get there — the return path from production
back to the spec.

Open questions

• How hands-on? Attendees run it themselves (setup, keys, network on-site), follow a replayed
  session, or a split — guided demo, then hands-on on a prepared environment? This drives everything else.
• Which business problem? Recognizable to a finance audience, small enough to build live, rich
  enough to have real decision structure — and with a plausible catch-all branch, if we want step 7.
• What does the front matter carry? Step 2 is the newest piece and the one people will push on.
• What is "a working system" at step 6? Which generator, what shape of deliverable.
• Step 7: how far can we get? What produces the "production" data, and what does the branch-coverage
  view look like — do we have anything today or is it built from scratch?
• Owners and a date for the first full dry run.