Compile on publish: faster AI workflows without losing traceability

The runtime got faster. It was no longer the same application.

A lender runs a multi-tenant credit-release workflow. It loads a tenant-scoped account, calculates exposure, checks policy, asks a person to approve when required, and releases credit through an enterprise API.

The first version interprets the workflow on every request: read the step definitions, resolve mappings, build validators, bind policy and API clients. It's easy to inspect, but at high volume the per-step overhead adds up.

So the team adds a compile step at publish. It precomputes branch conditions, fuses deterministic calculations, generates serializers and caches policy results it considers pure. Throughput improves.

Then a hidden assumption bites. Tenant and legal entity reach the policy service through ambient runtime context. They were never declared as inputs to the policy step. The optimizer sees a function of amount and risk tier, and caches the result on those two values.

Tenant A allows automatic release for a given amount and risk tier. Tenant B requires review for the same values. The fast path reuses Tenant A's cached decision for Tenant B. The API request is valid, the policy step is still on the diagram, and the runtime logs a cache hit, not an error.

No optimizer bug was needed. The optimizer preserved exactly the meaning it was given. The definition failed to declare a dependency that controlled the outcome.

Does a visual workflow have to run slowly?

No. People review a visual definition; the runtime can execute a prepared plan derived from it. The two can differ in form as long as each runtime step traces back to its source.

Visual architecture is often framed as a trade-off: keep the application inspectable and pay for interpretation on every request, or generate fast code and let the diagram go stale. That's a false choice. It mixes up two questions:

• What should people use to design, review and govern the application?
• What should the runtime use to execute it efficiently?

A visual view is built for people. The stored definition is built for completeness and versioning. A compiled plan is built for dispatch. Execution evidence is built for investigation. These don't have to be the same artifact. They have to stay linked. (For why the visual definition must stay in charge, see visual architecture vs no-code.)

What does compile on publish actually do?

It validates the workflow, pins its dependencies, prepares everything that doesn't change per request, adds evidence hooks and packages the result, once, at publish time, so requests run a prepared plan.

The publish pipeline has six stages:

1. Normalize. Put expressions, schemas, mappings, policy references and dependency IDs into one standard form, so equivalent definitions produce the same result and can be fingerprinted.
2. Validate. Type-check inputs, outputs and mappings. Find unreachable branches, illegal loops, ambiguous joins and missing failure routes. Check that policy covers every consequential step, authority carries through, approvals bind to proposals and side effects are classified. Schema validation is one input, not the whole check.
3. Resolve. Pin schemas, mappings, policies, sub-workflows, integrations, model routes and environments. Produce a dependency manifest for the release.
4. Optimize. Precompile expressions, mappings, validators, serializers and query plans. Fuse safe adjacent steps. Pre-bind dispatch. Remove repeated reflection, conversion and parsing, but only where it can't change meaning.
5. Instrument. Bind correlation, policy, lineage, cost, latency, state, approval and side-effect evidence into the plan itself, not onto whatever code happened to come out.
6. Package. Produce the plan, a traceability map, a build manifest, fingerprints and signatures, the same release-integrity disciplines secure-development guidance asks of any software build.

This is also where hidden assumptions turn into errors. If a policy result depends on tenant and purpose, those must be declared inputs. If a mapping drops classification or scope, the edge is rejected. If an approval binds to a proposal fingerprint, a later payload can't be swapped in without re-approval.

What can a compiler safely optimize?

Anything that can't change authority, state, ordering, side effects, policy, evidence or visible values. Everything else needs declared dependencies, or stays exactly where the workflow put it.

Enterprise rules make locally equivalent steps globally different. A policy check before tenant scoping isn't the same as one after. Approval before a material mapping change isn't the same as approval after. A retry before reconciliation isn't the same as one after.

Check that the application stayed the same

A normal compiler proves the output preserves the language's semantics. An enterprise workflow carries more obligations than that. Before release, check the compiled plan still preserves:

• input, output, mapping and failure contracts;
• identity, delegation, tenant, purpose and resource scope;
• where policy runs, its obligations and their enforcement;
• waits, events, timers and resume rules;
• approval binding to the exact proposal, its conditions and expiry;
• side-effect class, operation ID, retry and reconciliation (see retries and idempotency);
• required lineage, cost and audit evidence.

Some of this can be checked statically. The rest needs generated tests, simulation on representative cases or runtime assertions. "It compiled" and "the application is unchanged" are different release claims.

Fail closed. If the pipeline can't prove or test a consequential transformation, don't apply it. A slower correct plan beats a faster one whose controls you can't defend.

Keep a map from runtime back to source

Source maps let developer tools relate generated code back to the original file. A compiled workflow needs the same thing at the level of meaning, not line numbers.

For any error, latency spike, policy denial, unexpected branch or external effect, you should be able to name the published version and compiler version; the step, edge, mapping, policy check or approval it came from; the optimization passes that touched it; and the inputs, state, authority, cost and evidence of that step.

That gives operators source-level inspection: click a step in the visual workflow and see its latency, errors, retries, cost and policy outcomes, even if it was fused into a compiled segment. An incident record navigates back to the exact definition that allowed the behavior.

Will compiling make an AI application faster?

Only the coordination around the slow parts. Most AI workflows spend their time waiting on models, data, networks, people or external systems, and compiling doesn't shorten any of those.

Don't sell compilation as a universal latency cure. The real gain is narrower: removing repeated work in workflows with many small deterministic steps, high volumes, frequent mappings and validations, or deterministic-first paths that skip model calls entirely.

Measure before and after, rather than assuming parsing is the bottleneck:

The best optimization is usually not "make every step faster." It's taking repeated work out of the hot path while keeping every check whose answer depends on the current person, record, policy and state.

Agents and long-running cases still fit

A compiled plan doesn't need the whole path known in advance. A model may propose a classification, tool request or short plan. Events arrive whenever. People pause the work. What compilation fixes in advance is the boundary: which proposal shapes are allowed, which actions are open under which authority, and which validation, budget, approval and evidence rules apply whatever path is taken. A model-generated plan stays data until it passes those checks.

Each case records the published version and plan fingerprint it started under. A later publish creates a new plan for new cases. Cases already waiting don't silently pick it up; moving them is a deliberate, validated migration. Replaying a past case uses the plan that actually ran. Recompiling today against newer dependencies is a what-if, not a reproduction. (See versioning AI workflows.)

Common anti-patterns

Ten rules for compile on publish

1. Keep one authority: the published version. The compiled plan is its output.
2. Compile only from declared dependencies, never ambient context.
3. Validate types, mappings, policy coverage and approvals before optimizing.
4. Put fences around every consequential control.
5. Check that application obligations survive, not just language semantics.
6. Fail closed when a transformation can't be proven or tested.
7. Build evidence hooks into the plan.
8. Map every runtime event back to its source step and version.
9. Fingerprint and sign the release, with its dependencies.
10. Keep running cases on the plan they started with.

The result: inspectable and fast, without a second source of truth

The case for visual architecture isn't that people can draw boxes. It's that one definition can be reviewed visually, validated formally, compiled efficiently, executed durably and investigated through evidence.

A compiler only helps if it treats contracts, identity, policy, state, approvals, side effects and evidence as part of the program, not annotations around it. The goal is a verifiable path from the reviewed workflow to what runs, and an equally strong path back from any runtime event to the definition that allowed it.