Orchestrate: The Engine That Closes the Generative Cycle

Part of the Inner Agility thesis. This post describes Harness Engineering applied to UI composition — permissions, validation gates, and chained workflows that constrain AI to composing, never rewriting. Read the thesis →

In our Layers of Resolution post, we described four layers — Components, Workflow Stories, Pages, and Customer Forks — and a bidirectional generative cycle: workflow stories generate pages, and pages generate new workflow stories. The Red Pencil vision showed a user clicking a pencil icon, describing a change in natural language, and watching the system materialize it.

What we did not define was the runtime mechanism that closes this loop.

The pencil icon is a UI concept. The component catalog is a data structure. The workflow stories are documents. But the thing that watches for a change, triggers an AI, interprets intent, and propagates the result to the correct layer — that orchestration layer was missing.

We are calling it Orchestrate.

What the Architecture Needs

Think about what happens when a business analyst clicks the Red Pencil on the Budgets page and types "add an expense breakdown chart above the budget list." The UI can capture that intent. But then what?

Something needs to:

1. Detect that a page composition changed
2. Feed the change to an AI along with the component catalog and architecture rules
3. Let the AI reverse-engineer the intent and produce a workflow story
4. Write that story to the correct location
5. Validate the output against the catalog
6. Trigger the reverse direction — story generates updated page

This is not a single function call. It is a chain of events, each output becoming the next input, with quality gates between them. It is orchestration.

Two Directions, One Engine

Direction 1: Page → Use Case

A user modifies a page composition through the Red Pencil. Without orchestration, that composition file sits there. Someone manually interprets the change and writes a use case. The generative cycle is broken.

With Orchestrate, the chain fires automatically:

User saves composition → Orchestrate detects change → AI fires with catalog context →
Intent reverse-engineered → Workflow story written → Story validates → Use case exists

The orchestration layer watches page composition files. When one changes, the AI reads the new layout, compares it against the previous version, and produces a workflow story entry — a named use case with a component sequence, props, layout, data hooks, and the user journey it serves.

The use case did not exist before the user touched the page. The page created the use case.

Direction 2: Use Case → Page

A business analyst writes a new workflow story. Or the SDLC pipeline advances a document from specs to on-deck. The orchestration layer detects the change and generates the page.

Story file written → Orchestrate detects change → AI fires with catalog context →
Page composition generated → Composition file written → Dynamic page loader renders it

No deploy. No code change. The use case materialized a page.

Chained Workflows: The Quality Gate

Single-step orchestration is not enough. One step's output triggers the next step's input, and the critical middle link is validation:

Page composition changes
  → Step A: Reverse-engineer use case → writes workflow story
    → Step B: Validate story against catalog → writes validation report
      → Step C: If valid, generate updated page composition
        → (Loop stabilizes when no diff is detected)

Step B — the validator — is the quality gate. It checks:

• Every component referenced in the story exists in the catalog
• Every data hook referenced is exported from the correct domain package
• The props interface matches the component's TypeScript declarations
• The route does not collide with existing routes
• The use case name follows naming conventions
• Cross-domain dependencies are flagged as architecture violations

If validation fails, the chain stops. No invalid composition reaches the page loader. The validator is not a nice-to-have — it is what makes the generative cycle safe enough to give to business analysts.

Skills as the Catalog Delivery Mechanism

Our blog posts have described the AI needing the component catalog "as context." But injecting context manually into every prompt does not scale. The orchestration layer formalizes this through a skills system — domain-specific documents automatically injected into the AI's working context when a chain fires.

Skills follow an override convention: project-level skills override global skills. This means customer forks can provide their own component catalogs that extend or override the default, and the orchestration layer uses the fork-specific catalog automatically. The skill system is what makes the same engine work across tenants without per-customer prompt engineering.

The Permissions Layer as Safety Net

An AI that can read your codebase and write files needs guardrails. The orchestration layer enforces permissions at every step:

The AI operates within the composition layer — never touching the proven, tested component packages underneath. It can rearrange the building blocks. It cannot rewrite them.

Two Trigger Paths

During development, the orchestration layer watches the file system. A developer saves a workflow story, and the chain fires. This is the inner loop — fast iteration with immediate feedback.

In production, users do not save files. They interact with a UI. The same orchestration engine handles this through a webhook path:

Red Pencil UI → POST /orchestrate/compose → Chain fires →
AI generates composition → Response returned → UI renders preview

Same skills. Same permissions. Same validation gates. Different trigger mechanism. The webhook path is what makes the Red Pencil feel interactive — the user types a description, the system returns a live preview composed from the component vocabulary.

This is the bridge between development-time tooling and runtime behavior. We build and test with file watching. We ship with webhooks. The orchestration logic is identical.

What We Would Build vs. What Already Exists

The orchestration pattern is not new. Event-driven systems that watch for changes and trigger downstream actions exist across the industry — CI/CD pipelines, database triggers, serverless event buses. What makes this specific is the combination: AI-powered interpretation, catalog-constrained generation, and bidirectional propagation across architectural layers.

Patterns we adopt:

• Event detection with smart batching (debounce rapid saves)
• Hook definitions as declarative configuration (not imperative code)
• Chained workflows where one output triggers the next input
• Pre/post processing for validation and formatting
• Permission rules with deny-by-default safety

What we build new:

• The composition file format and JSON schema
• The page-to-use-case reverse engineering prompt
• The use-case-to-page generation prompt
• The validation chain with catalog-aware checks
• The dynamic page loader that consumes composition files
• The Red Pencil UI with webhook integration
• Customer fork management across tenants

Where This Sits in the Roadmap

Orchestrate is a Phase 3 accelerator. It does not change Phase 1 or Phase 2 work — those remain: finish the JE-PFM integration, build iCashflow. But it sharpens Phase 3 by replacing a hand-waved "and then the AI figures it out" with a concrete, testable architecture.

The sequencing:

1. Phase 1 (current): POC 2 produces the component catalog. POC 3 builds the AI chat prototype. POC 4 builds the dynamic page loader. These are all prerequisites for orchestration.
2. Phase 2: iCashflow adds new components and use cases to the catalog, expanding the vocabulary the generative cycle can draw from.
3. Phase 3: Orchestrate connects the catalog, the page loader, and the Red Pencil UI into a closed generative loop.

The architecture decisions we make now — particularly the composition file format and the catalog schema — must be designed with this orchestration layer in mind. The format must be diffable, validatable, and AI-interpretable.

Open Questions

We are publishing this as a vision, not a spec. Several questions remain open:

Stabilization. When the page-to-story chain and the story-to-page chain both fire, how do we prevent infinite loops? Diff deduplication handles identical outputs, but what about semantic equivalence with syntactic differences?

Latency. The webhook path needs to feel interactive. What is the acceptable latency budget, and can a single AI round-trip meet it? This may require a tiered approach — fast draft generation with slower validation.

Prompt quality. The page-to-use-case direction (reverse engineering intent from a composition diff) is harder than use-case-to-page (generating a known format from a spec). This is the prompt that will require the most iteration.

Fork conflicts. When two users modify the same page composition simultaneously, who wins? Last-write-wins is simple but may not be sufficient for customer forks.

We do not need answers to these questions before Phase 1 is complete. But we need to be thinking about them as we design the composition format and the catalog schema, because those are the data structures that Orchestrate will consume.

What Comes Next

The Layers of Resolution post ended with a promise: the default-pages catalog enables the AI chat prototype. That remains the immediate next step. But now we know what sits on the other side of that prototype — not just a chat that suggests components, but a full orchestration engine that closes the generative cycle.

We are still in Phase 1. The orchestration layer is a Phase 3 deliverable. But the vision is no longer hand-waving. It is an architecture with named concepts, defined boundaries, and testable chains. Every POC we build now is a piece of the engine we will assemble later.

The generative cycle has an engine. We are calling it Orchestrate.