Narrative

When something breaks in production, what happens next? You open a dashboard. You grep logs. You page someone who was on-call last year. You stitch together a story from fragments: a timestamp here, an error code there, maybe a Slack thread from the incident channel. Hours later, if you’re lucky, you have a plausible explanation. But you can’t prove it. The evidence is so fragmented and partial that any narrative is a work of fiction that’s based on a true story.

Narrative is where causality, history, agency, and intent converge. It’s about the coherent story the system can tell about why something happened, who made it so, and what it was trying to do. A system that can form a narrative empowers operators, auditors, and users. It enables the humans around it to learn, a full circle moment after all the machine intelligence we invest to reach higher levels of maturity.

To illustrate how narrative matures, we’ll follow a single scenario across all five levels: a trade rejection in a portfolio management system. At each level, we’ll see what the system can (and cannot) tell us about what happened.

To evaluate narrative integrity, we define five levels:

• N0: The Blank Page: The system exposes terse fragments of narrative data like logs, events, and traces
• N1: Operationalized Speculation: Operators gain some understanding of system stories by manually stitching together narrative fragments
• N2: Structured: The system emits structured event chains that support basic timeline reconstruction
• N3: Reconstructable: The system encodes and links all CHAI(N) data to generate full storylines
• N4: Explainable: The system narrates itself; it can describe past behaviour and justify outcomes

Narrative is where all other CHAIN dimensions culminate. Causality, History, Agency, and Intent (CHAI) provide the raw materials, but without deliberate investment in making those materials narratable, systems remain stuck at N1: doing manual forensics over increasingly rich data that nobody can easily query or traverse. CHAI maturity is necessary but not sufficient. It enables narrative maturity, but doesn’t produce it automatically.

N0: The Blank Page

At N0, you’re reading entrails. Something happened, like a trade didn’t go through, but the system can’t tell you why. Maybe there’s a log line somewhere, or maybe an error code, but there’s no cohesive narrative. Any narrative is speculation.

The trade rejection at N0:

2025-04-15 12:01:14 ERROR TradeService: order failed, code=REJECTED
2025-04-15 12:01:14 WARN  ComplianceCheck: rule violation
2025-04-15 12:01:13 INFO  PortfolioService: rebalance triggered

Three log lines. No correlation. No actor. No intent. You can make an educated guess that they’re related because the timestamps are close, but you can’t prove it. Was the rejection caused by the compliance check? Which rule? Who triggered the rebalance? Why? The system doesn’t know, and neither do you.

But you’ll come up with a story anyway. You have to. Customers demand explanations. Executives want root causes. Investors need confidence that someone understands what went wrong. The pressure to deliver narrative doesn’t disappear just because the system can’t support it; it falls on engineers to fill the gap manually. And they will produce a story even when they can’t be sure, because the alternative is career friction. Imagine walking into a performance review where every incident you handled concluded with “we can’t be certain what happened.” Imagine your reputation with peers and leadership if your answer is always “I think this might be what happened, but there’s no way to prove it.” Nobody takes that gamble. A system at N0 forces its operators to gambit constantly, delivering confident narratives built on speculation.

What the system emits at N0:

• Logs: Un/semi-structured text blobs with no correlation IDs, actor references, or session context
• Traces: Raw function calls or RPC spans, disconnected from any user intent or business goal
• Metrics: CPU, memory, and latency SLIs that reflect technical symptoms, not behavioural outcomes
• Events: Machine-native signals like row_updated or job_exited with no domain framing

You can’t:

• Trace a user action across systems
• Reconstruct a timeline from intent to outcome
• Attribute a decision to a specific actor or goal

To escape, the system must begin telling its own story. That means raising CHAI links across the board:

Until then, the system offers fragments. At this level of maturity, teams also don’t have processes to deal with the gaps. They would struggle to craft a postmortem analysis or RCA. Strange times, indeed.

N1: Operationalized Speculation

N1 wraps the same incomplete data in process, tooling, and ritual: incident channels, runbooks, RCA templates, post-mortem meetings. The formality creates an illusion of rigor. The “5 whys” exercise feels like root cause analysis, but if the underlying data is fragmentary, you’re just asking “why?” about your best guesses.

N1 adds legitimacy. N0 narratives live in Slack threads and get forgotten. N1 narratives get written into official documents, reviewed in meetings, signed off by leadership. They look provable. They’re still speculation. The system still requires deep tribal knowledge, but now the people responsible for its health have rituals for translating fragments into a cohesive story, but only after the fact.

The trade rejection at N1:

A PagerDuty alert fires. The on-call engineer joins the incident channel, opens Kibana, and starts grepping. After 45 minutes, they’ve pieced together a timeline:

“Looks like the Portfolio Service triggered a rebalance at 12:01:13. That spawned a sell order for AAPL. The Compliance Service rejected it, probably rule R-19 based on the error code. The trade never retried. We think the SLA window expired, but we can’t confirm because that service doesn’t log timeouts.”

The story exists, but it lives in a Slack thread. Tomorrow, someone will copy it into a Google Doc. Next month, no one will remember the details.

The defining characteristics at N1 are the incident channel, a shared runbook, and a post-mortem template that serve as your narrative interfaces. Every SEV-1 pages a team that lives in tail -f | grep, flips through runbooks, and hand-assembles a timeline. But the process for this now exists.

What the process looks like:

Teams typically formalize a small set of Service Level Indicators (SLIs) and Service Level Objectives (SLOs) at this stage. Site Reliability Engineers (SREs) are often responsible for constructing the narrative around major incidents, usually in the form of Root Cause Analysis (RCA) reports. These numbers tell you when to trigger an incident and whether to write an RCA, but the timeline still depends on manual log diving and expert intuition.

You can reconstruct a coherent story at N1, but only by:

• Relying on tribal experts who know which logs matter
• Correlating trace IDs by hand or with ad-hoc scripts
• Spending hours sifting through symptom-first dashboards

At this maturity level, the resulting narrative is manual, fragile, and slow to produce. It captures knowledge, but only after the fire is out, and only if the humans remember (or are nudged) to write it down. Repeat incidents require the same detective work because the system itself records no structured storyline.

N2: Structured

The system begins to emit structured sequences of events that can be correlated into a timeline. Unlike N1, where narrative lives in war rooms and postmortems, N2 encodes enough context that the story can be reconstructed directly from the data.

The trade rejection at N2:

SELECT event_type, actor_id, ts
FROM events
WHERE correlation_id = 'rebalance-wf-8821'
ORDER BY ts;

Now we can see the sequence. The Portfolio Service detected an imbalance, issued a rebalance command, and the Trade Service submitted a sell order. The Compliance Service rejected it. But why was it rejected? Which rule? What was the original goal? The system still can’t say.

At this maturity level, every event carries a “minimal narrative envelope”:

{
  "event_id":         "01HY3...",
  "event_type":       "TradeRejected",
  "ts":               "2025-04-15T12:01:14.019Z",
  "correlation_id":   "rebalance-wf-8821",
  "causal_parent_id": "01HY2...",
  "actor_id":         "svc-compliance",
  "payload":          { "order_id": "ord-4412", "reason_code": "RULE_VIOLATION" }
}

With this envelope in place, timeline reconstruction becomes a query rather than ad-hoc forensics. The defining characteristic of N2 is that a structured query can tell the story.

You can now:

• Follow a chain of events across services and time
• Attribute steps to actors, human or machine
• Reconstruct a timeline directly from data

This level of maturity typically emerges once all services begin emitting structured domain events that include trace or workflow correlation. Log lines, spans, and events are tied together under a shared key (often a correlation_id) which allows operators and developers to trace the flow of a request or workflow across systems with a single query. These events are commonly encoded in formats like JSON or Protobuf and durably stored, making them reliable sources for narrative reconstruction.

However, limitations remain. The story is still emergent. It can be pieced together after the fact, but the system doesn’t yet recognize that it’s telling one. Causal links such as causal_parent_id may be present, but they exist as singly linked references, not as part of a navigable causal graph. And intent is still absent; while we can observe what happened and who triggered it, the system offers no structured field to explain what outcome was expected or why a given action occurred.

N2 is the first level where you can say, confidently:

“This is what happened, and this is who did it.”

But the system still can’t say why, or much of anything on its own without prompting.

N3: Reconstructable

At this level, the system records every part of the story. Events are connected by causality, associated with real actors, tied to declared goals, and stored in a way that can be replayed or inspected at any point.

The trade rejection at N3:

Now we can query the causal graph:

SELECT e.event_type, e.actor_id, e.ts, e.intent, c.causal_parent_type
FROM events e
JOIN causal_edges c ON e.event_id = c.child_id
WHERE e.correlation_id = 'rebalance-wf-8821'
ORDER BY e.ts;

Now we can see the why. The original intent was to maintain a 60/40 risk profile. The system detected a sector imbalance and issued a rebalance command to reduce tech exposure. The trade was submitted to execute that rebalance. The Compliance Service rejected it to enforce risk limits. We can also see the causal chain: each event links to what triggered it.

The system captures enough information to reconstruct full workflows. You can trace how an outcome came to be, what actions led to it, who performed them, and what they were trying to accomplish. This is a large step up from N2. It requires consistent maturity across the entire CHAI model.

With these links in place, the system can:

• Reconstruct entire workflows using causal relationships (rather than using basic correlation IDs)
• Attribute each action to a specific actor, whether human or service
• Replay any part of a timeline to simulate alternate outcomes
• Compare intent to results, and surface where they diverged
• Explain outcomes in terms of what was triggered, when, and by whom

This level of maturity usually emerges when events and commands are modeled as graph nodes with explicit causal edges, allowing the system to trace how outcomes unfold over time. Snapshots or projections can be rolled back and reapplied without loss, making historical state both durable and replayable. Actor identity is validated at the time of action and included in event metadata, ensuring that every decision is attributable. Commands also carry intent fields that persist through the resulting events, preserving the original purpose behind each action as part of the system’s record.

At this point, narrative is encoded deliberately. Operators can read the chain of events from cause to effect. Engineers can simulate what would happen if a different action had been taken. Auditors can confirm whether a decision respected its original intent.

This is the first level where you can say:

“This is what happened, why it happened, who did it, and what they were trying to achieve.”

The system records the data and the decisions and motivations that shaped it. The story is present. But you still have to ask for it.

N4: Explainable

The system now speaks for itself. It knows what happened, who made it happen, what they were trying to do, and whether it worked or not. It does not whisper in fragments. It tells you, plainly.

The trade rejection at N4:

You ask the system: “Why was order ord-4412 rejected?”

The system responds:

“On April 15 at 12:01 UTC, the Portfolio Service detected a sector imbalance in account ACCT-7291. The account’s tech allocation had drifted to 68%, exceeding the target 60/40 profile configured by the account holder. A rebalancing command was issued to reduce tech exposure by selling 50 shares of AAPL. The Trade Service submitted the sell order. The Compliance Service blocked the trade due to rule R-19: the proposed sale would have exceeded the account’s daily loss threshold of $10,000, given the current unrealized losses. No retry occurred because the 30-second SLA window expired before the risk parameters could be recalculated.”

This isn’t a log dump. It’s a coherent narrative, generated from the CHAI-linked data, that explains what, who, why, and whether it worked.

At this level, narrative is a first-class product of the system. The causal graph is complete. History is durable and queryable. Agency is verified. Intent is modeled and validated. Each part of CHAI is working together.

You can ask questions of the system, like:

• “Why was this trade rejected?”
• “Did this workflow do what it was supposed to do?”
• “Who initiated this action, and under what policy?”

The answers come in full sentences, backed by facts.

This level supports:

• Plain-language postmortems written from replayed timelines
• Audit reports generated from the causal graph itself
• AI agents that explain what they just did
• Regulatory disclosures backed by verifiable data
• Real trust, earned by the system’s ability to justify its own behavior

At this point, the system supports engineers with rich narration, rather than the engineers serving the system by writing stories after an incident. The system produces it. The words are generated by templates, rule engines, or language models—but the source of truth is the CHAI-linked data.

There are many ways to do this. Some teams build structured templates. Others use lightweight rule-based generators that map causes and effects to short phrases. More advanced teams are using LLMs to turn graph extracts into narrative. The best systems combine all three: a deterministic core, surrounded by language that makes it understandable.

This can happen in a CLI tool, a timeline viewer, or a chat interface. The interface does not matter. What matters is that the system understands its own story, and can share it without error or evasion.

At N4, narrative comes full circle. We started this journey because systems couldn’t explain themselves. Now they can. The system can justify its past. It can explain what it did. It can name the actor and show the intent. It can walk you through the decisions. And in doing so, it gives the humans around it what they need most: understanding.