Chapter 2: Bringing Data In

Understanding Data Flow

When building automated workflows across multiple steps, one of the biggest headaches is keeping track of where your data is. In traditional automation platforms, data is heavily nested. To print a client's name in a PDF, you often have to write complex paths like {{steps.trigger.payload.clientName}}.

Strucsta eliminates this complexity by utilizing a Cumulative Context Model.

The Cumulative Context Model

Strucsta is purpose-built for short, highly focused document generation pipelines ($Ingest \to Reason \to Render$). Because workflows are typically linear and short-lived, the engine merges data flatly as it moves from step to step.

Instead of nesting the output of each step into its own separate object, Strucsta continuously builds upon a single, master JSON state.

How State Evolves

Let's look at a practical example of a "Client Onboarding Contract" workflow to see how the state builds over time:

1. The Ingest Step (Webhook or Form)

Data enters the system. The engine creates the initial state payload based on the incoming fields.

Internal State:

{
  "clientName": "Acme Corp",
  "subscriptionTier": "Enterprise",
  "basePrice": 5000
}

2. The Reason Step (AI Logic)

The data is passed to the LLM. The AI evaluates the subscriptionTier and basePrice to generate an onboarding summary and select the appropriate compliance clauses.

When the AI returns its strict JSON output, the engine does not bury it in a reasoning object. It merges it directly into the root level of the existing state.

Internal State:

{
  "clientName": "Acme Corp",
  "subscriptionTier": "Enterprise",
  "basePrice": 5000,
  "executiveSummary": "Acme Corp is an Enterprise client requiring a custom SLA...",
  "requiresCustomSLA": true
}

3. The Render Step (PDF Generation)

By the time the data reaches the pdfmaker step, the template engine has access to the complete, flattened context of the entire run.

Designing Templates with Cumulative Context

Because the context is flat, designing your JSONC templates becomes incredibly intuitive. You do not need to remember which step generated which piece of data.

If you want to inject the client's name (from the Ingest step) and the summary (from the Reason step), you simply reference them directly using Handlebars syntax:

{
  // ... pdfmaker boilerplate
  "content": [
    {
      "text": "Prepared for: {{clientName}}",
      "style": "header"
    },
    {
      "text": "{{executiveSummary}}",
      "style": "body"
    }
  ]
}

Handling Data Collisions (Refinement)

What happens if the AI step outputs a JSON key that already exists from the Ingest step? The downstream step overwrites the existing key.

This is a powerful, intentional feature called Data Refinement.

For example, a client might submit a raw, unstructured block of text in a form field called projectDescription. In your Reason step, you can instruct the AI to clean up the grammar, format it into bullet points, and output it back out using the exact same projectDescription key. The state is updated with the clean version, and your PDF template seamlessly prints the refined text.