ICC-GO: Run Manifests for LLM Workflows

A local-first notebook that records what each LLM workflow run actually used: prompts, files, model route, artifacts, and upstream run IDs.

Comment

Inspiration

A lot of useful LLM work starts in chat, but the moment the work becomes multi-step, the transcript stops being a reliable engineering artifact. You may have files, model choices, intermediate outputs, review passes, generated artifacts, and downstream steps that depend on earlier runs. Later, when someone asks “what actually produced this result?”, the answer is often hidden across a conversation history.

ICC-GO started from that frustration. The idea behind Intent-Cell Coding is simple: keep the human-readable intent, routing, constraints, references, and output contracts together as notebook cells, then make each cell rerunnable and inspectable.

During Build Week, developer feedback pushed the project in a sharper direction: “reproducible” should not mean pretending remote LLM calls will replay byte-for-byte. It should mean that the execution trail is visible enough to inspect, rerun, compare, export, and attribute.

What It Does

ICC-GO is a local-first notebook for multi-step LLM workflows. A workflow is written as intent cells: readable task text plus compact ICC DSL lines for things like model routing, constraints, references, branching, and file outputs.

For this Build Week submission, the main addition is a Run Manifest & Provenance Inspector. After a cell runs, ICC-GO records a manifest with the concrete facts behind that execution:

  • the cell revision and requested route;
  • resolved provider/model observations;
  • input attachments and content digests;
  • upstream %from references resolved to specific run occurrences;
  • consumed and produced artifacts;
  • decision/branch results;
  • warnings about moving targets such as alias routes;
  • exportable manifest, artifact, and attachment indexes.

The important behavior is frozen upstream binding. If c2 used a particular c1 run, then rerunning c1 later does not rewrite history. The old c2 manifest still points to the original upstream run and artifact occurrence it consumed.

How I Built It

The app is built with React, TypeScript, Vite, and a local-first workspace model. ICC DSL parsing, runtime planning, run history, artifacts, exports, and the inspector UI live in the front-end codebase so the workflow remains easy to test locally.

During Build Week, I used Codex with GPT-5.6 as the main build partner. Codex helped turn community feedback into a concrete feature scope, then worked through the implementation details: the manifest data model, digest/index generation, frozen reference semantics, export ZIP additions, Run Inspector UI, tests, documentation, and submission materials.

The feature is intentionally split into two layers:

  1. ICC DSL remains the authoring layer: readable, compact, and close to what the developer meant.
  2. Run manifests become the execution layer: the durable record of what was resolved, consumed, produced, and exported.

That separation became the core product decision.

What I Learned

The biggest lesson was that “reproducibility” is too broad a word for LLM workflows unless it is defined carefully. For deterministic build systems, reproducibility can mean identical outputs. For multi-provider LLM workflows, the more honest and useful target is inspectability and comparability.

A good AI workflow record should answer questions like:

  • What model route was requested?
  • What provider/model was actually observed?
  • Which file or artifact version was used?
  • Which upstream run did this output depend on?
  • What changed between two runs?
  • Can this workflow be exported and inspected outside the app?

That is a better foundation than trying to reconstruct truth from chat history.

Challenges

The hardest product challenge was avoiding overclaiming. It would be easy to say “rerunnable means reproducible,” but that is not quite true when remote models, aliases, tools, and changing context are involved. ICC-GO now records warnings for moving targets and keeps the language focused on inspectable, rerunnable, comparable, and attributable workflows.

The hardest implementation challenge was preserving historical lineage. While authoring, references like %from c1 naturally point to the latest upstream result. But after a downstream run completes, its manifest must freeze the exact upstream run occurrence it consumed. That distinction between live authoring references and completed execution records is small, but it matters a lot.

Another challenge was keeping the feature local-first. The manifest needs to be useful without a hosted backend, so exports include the notebook state, run history, manifests, artifact indexes, attachment indexes, and generated files.

What Is Next

The next step is to make comparison workflows richer: better visual diffs between runs, clearer provider observation metadata, and optional bridges to external tracing systems. But the base layer is now in place: ICC-GO can keep the readable workflow and the execution trail side by side.

Share this project:

Updates