In This Series

Part 1 — Data as National Infrastructure
Part 2 — How Data Becomes an Industrial Asset: Yang Jae-soo’s Framework for Verification
Part 3 — DataStreams Takes Trusted, AI-Ready Data Ecosystems Global
Part 4 — FLock.io CEO Jiahao Sun on Keeping Data Local While AI Learns
Part 5 — Hasibul Haque Links Operational Context to AI Accountability
Part 6 — Analysis: Korea’s Data Competitiveness Rests on Verifiable Industrial Results

Operational Context Is the Missing Link in AI Accountability

As AI agents move from generating answers to modifying code and production systems, access to more enterprise data is no longer enough. Agents also need to understand how code, infrastructure, security policies, ownership and runtime events relate to one another. Without that operational context, an agent may identify a technically plausible change while missing the dependencies, business rules or past incidents that determine whether it is safe.

Hasibul Haque, CEO of Causal Dynamics Lab, argues that enterprises need a structured representation of their production environments. In his responses, he describes Cielara’s Production World Model as a causal map connecting what code does, why it exists, who owns it, what constrains it, where it runs and what happens after deployment.

Haque also describes a Decision Trace that records the evidence an agent used, the authority under which it acted, the person who approved the change and the operational outcome. Together, these concepts present AI accountability as an engineering system embedded in everyday operations, rather than a review conducted only after an incident.

The following is a written Q&A with Hasibul Haque, CEO of Causal Dynamics Lab. 

Q1. Operational context as the real constraint

Many enterprises now have large volumes of operational data, yet AI agents still struggle to understand how code, infrastructure, policies, ownership and runtime events interact. Why has the absence of operational context become a more serious constraint than the availability of data itself?

Enterprises don't have a data shortage. They have years of logs, traces, tickets, commit history, policy documents and org charts. What's missing is the relationships between them. Which service calls which. Which policy governs which data path. Who owns the thing that's about to break. Why a timeout that looks wrong was set that way three years ago.

A senior engineer carries that in their head, and a new hire needs three to six months to build it. An AI agent gets none of it. It sees text.

We instrumented coding agents to see where their time goes. Across 2,510 actions, 56.8% were file reads, 24.2% were grep, and under 1% were edits. 82% of failures were navigation failures. When a fix spanned more than six files, recall fell from 0.579 to 0.143. The agent isn't failing to think. It's failing to find.

One of our papers, RCML, makes the same point from another direction. We showed that the same item should be represented differently depending on the relationship you're asking about, and doing so improved retrieval by roughly 31% on Hit@5 over a standard CLIP backbone. Operations work the same way. A service is one thing to the team that owns it, another to the security policy that governs it, and another to whoever gets paged at 3 a.m.

This became urgent because of speed. When people wrote all the code, the context lived in the people, and review caught most of the rest. Agents now produce changes faster than any team can review them, and the context didn't transfer with the work. DORA's research tied rising AI adoption to a 7.2% drop in delivery stability.

More data won't fix that, and neither will a bigger context window. The agent needs the structure, and today the structure isn't stored anywhere.

Q2. How the Production World Model is built

Cielara's Production World Model is described as a six-layer causal representation of what code does, why it was created, who owns it, what constrains it, where it runs and what happens at runtime. How is this model constructed from fragmented enterprise systems, and how does it turn operational data into knowledge that an AI agent can use?

It answers the six questions a good engineer asks before touching anything: who, what, when, where, why and how. What does this code do? Why was it built this way? Who owns it? How is it constrained? Where does it run? What happens, and when, once it's live?

Each answer lives in a different system. Function is in source code. Rationale is scattered across commits, pull requests, tickets and design docs. Ownership sits in code-owner files and the on-call rota. Constraints are in security and compliance policy. Topology is in infrastructure-as-code. Runtime behavior is in telemetry and incident history.

We start with code, the most precise source, and parse it into a graph of services, files, classes and functions connected by imports, invocations, inheritance and containment. Then we attach the other five layers to the same nodes. The hard part is entity resolution: proving that the “payments-api” in a ticket, a Kubernetes manifest and a dashboard are the same thing. The edges are causal, built on structural causal models, so the graph can answer “if this changes, what breaks, and why?”

Three pieces of our research make it usable by an agent. LARGER handles navigation: it starts from a lexical match, anchors it to the graph and expands only into high-confidence neighbors, inside the agent's existing search loop, with no separate graph database. Reasonara and MemOnDemand handle memory: each collection gets its own hierarchy, and compact routing records are kept separate from the detailed evidence. SkillLens handles know-how, organizing reusable skills into four layers of policies, strategies, procedures and primitives.

The result is that an agent asks a question and gets a focused slice of 100 to 400 tokens, where a raw file read costs about 3,000. Before a change ships, Foresight runs it against the model across 30+ failure types.

Q3. Tracing an AI-generated change end to end

Data provenance and lineage are becoming central to enterprise AI governance. How can an organization trace an AI-generated change from its underlying evidence and intent through approval, deployment and runtime impact? What records must be preserved for that chain to remain auditable and trustworthy?

My test: six months after an incident, can you reconstruct what the agent knew, what it was asked to do, who approved it, and what happened next? If any link is missing, you don't have governance.

We call the joined record a decision trace. It's the reasoning behind a change, captured as it happens and fed back to both the agents and the engineers, so the next decision starts from what the last one learned.

Seven records have to survive. The intent: the ticket, prompt or spec, and who requested it. The evidence: exactly which context the agent received, pinned to a version of the world model, because the model keeps changing and you need the snapshot it actually saw. The actor: which agent, which underlying model and version, which permissions. The change: the diff and the commit. The verification: what simulation ran and what it predicted. The approval: who signed off, when, and what they were shown. The outcome: the build hash, the environment, and the telemetry and incidents tied to the same change ID.

Two rules keep the chain trustworthy. Every record points to immutable identifiers, and the log is append-only. And a summary never stands in for the source. That's the core of our MegaMem and MemOnDemand work: distilled records help you find things, but an answer must resolve to original evidence.

Most enterprises already hold pieces of this in Git, CI/CD, ticketing and observability tools. Nobody joins them, so every audit becomes archaeology. A world model already links intent, ownership, constraint and runtime, so the provenance falls out of the architecture.

The record people forget is the approval context. “Approved” means very little unless you know what the approver was looking at.

Q4. Giving agents context while protecting data and IP

Enterprises are reluctant to expose proprietary code, production telemetry and internal decision records to external AI services. How can contextual AI systems give agents access to the information they need while maintaining data control, authorization boundaries and protection of sensitive intellectual property?

The reluctance is rational. Your code and production telemetry are the most complete description of how your company works. I wouldn't ship them to a third party either.

We follow five principles.

Bring the model to the data. Cielara deploys in the customer's own environment on AWS, Azure or GCP. The world model and memory are built and stored there.

Send slices. A conventional agent reads whole files and pushes them to an external model again and again. With a world model it asks a specific question and gets a few hundred tokens back. Our measured 30–40% cut in token consumption is also a cut in what crosses your boundary.

Bound the exposure. In our memory research the generator only ever receives a fixed budget of source evidence, however large the memory grows. We've tested that from 10M tokens to more than 600M. What an external model can see doesn't scale with the size of your corpus.

Inherit authorization. The world model knows who owns what, so an agent acting for a developer sees only what that developer may see. An agent should never become a way around access control.

Let the customer choose the model. Components can run on different providers, including ones the customer hosts, so the most sensitive workloads never touch an external API.

Every access is logged, which is what makes the rest verifiable. We hold a SOC 2 Type II report and publish our controls in a public trust center.

That combination is what lets the most cautious buyers say yes. One of the largest edtech companies and a Fortune 200 global bank are running Cielara on their own codebases today.

One piece of advice for buyers: ask any vendor exactly what leaves your environment, per request, in bytes. If they can't answer, they don't know.

Q5. How the results were measured and validated

Causal Dynamics Lab has reported improvements in code localization, task completion time and token consumption. How were these results measured, what independent validation is available, and which results from real enterprise deployments best demonstrate that causal context improves operational reliability?

I'll separate what's measured, what's published, and what hasn't been independently validated.

Code localization. Across SWE-Bench, MULocBench (1,033 instances, 46 repositories) and LocBench, Cielara Code reached 0.774 combined accuracy, against 0.738 for Claude Code on Opus 4.6 and 0.707 for Codex on GPT-5.2. Average time per task fell from 141.8 to 128.6 seconds, about 10%, and token use fell 30–40%. The method is public as LARGER: +13.9 points on file-level Acc@5 on LocBench with tuned settings, +11.8 with fixed settings, and consistent gains on MuLocBench and two SWE-Atlas tasks. I quote the fixed-settings number on purpose, because tuned numbers flatter everyone.

Memory. Reasonara holds 125M+ tokens of effective context at 94% accuracy with 98% fewer tokens than full-context retrieval. EnterpriseRAG-Bench simulates a company of 500,000+ documents and about 650M tokens. On its headline comparison, run at the 10M memory scale, MegaMem moved Overall from 68.22 to 82.26, and we then scaled it to 250M tokens under the same fixed evidence budget. MemOnDemand beat the strongest published result at every scale up to the full collection, by 12.23 points at 10M and 4.66 at full scale, and it holds up on FinanceBench, HotpotQA and FRAMES.

Agents. SkillLens raised ALFWorld success from 45.00% to 51.31% and bug localization Acc@1 by up to 6.31 points.

Validation. Every benchmark is public and built by others. The runs are ours. The papers are arXiv preprints written with Dr. Liang Zhao's lab at Emory, and code for MemOnDemand and Reasonara is on GitHub so anyone can rerun it. No third party has audited our numbers yet, and I'd welcome it. One limit I'll volunteer: these benchmarks test one repository at a time. None tests a coordinated change across services, which is where enterprises actually get hurt.

In production, the results have been stronger than the benchmarks. One of the largest edtech companies is seeing much better numbers on its own codebase than anything we've published, and a Fortune 200 global bank is seeing the same. That doesn't surprise me. Public benchmarks use clean open-source repositories. Enterprise code is bigger, older and more tangled, and that's where structure helps most.

Q6. Permissions, approval points and rollback

As AI agents gain authority to modify production systems, how should companies define permissions, human approval points and rollback procedures? Which decisions can safely be delegated, and which should remain under direct human control?

I score every proposed change on two questions. How far can the damage spread if it's wrong? And can we undo it?

Small blast radius and fully reversible: delegate it. Dependency updates, test generation, flaky-test fixes, refactoring inside one service, configuration changes inside predefined guardrails. With simulation before merge and automatic rollback after, a human adds little except delay.

Large blast radius or irreversible: a human decides. Schema migrations. Anything that deletes data. Identity, access and security policy. Payment paths and anything safety-critical. Contract changes between services owned by different teams. An agent can do 90% of the work on all of these. It shouldn't press the button.

Our SkillLens research uses a verifier that inspects each reusable step and decides whether to accept it, break it down, rewrite it or skip it. Permissions should work the same way: graded and per step, never all or nothing.

Three rules on approval. The approver owns the affected system. The approver sees the predicted impact, and the diff alone doesn't count. And approval is required whenever a change crosses an ownership boundary, however small.

On rollback: every agent change ships with a tested rollback. It triggers automatically when a service-level objective is breached, without waiting for someone to wake up. Each agent has its own identity with narrow, short-lived credentials, never a developer's borrowed keys. And there's one switch that stops all agent activity.

Permissions shouldn't be static either. An agent earns wider scope through a track record on a specific system, recorded in its decision traces, and loses it when that system changes underneath it. We re-verify trust continuously, the way we would with a new engineer.

Q7. Lessons for Korea and where Korean companies can compete

Korea is seeking to develop data as national and industrial AI infrastructure. What can policymakers and enterprises learn from production world models about interoperability, common semantics, data ownership and verifiable decision records? Where could Korean companies build a competitive position in this emerging market?

Korea's instinct to treat data as infrastructure is right. I'd push it one step further. The infrastructure that matters is the relationships in the data, and relationships need standards.

Five lessons from building production world models.

Interoperability starts with shared semantics. If two companies can't agree on what a “service,” an “owner” or an “incident” is, exchanging datasets achieves little. Standardize the vocabulary of entities and relationships first.

Ownership stays with whoever produces the data. The model should travel to the data. A strategy built on pooling everyone's operational data in one place will meet the resistance we see inside a single enterprise, for the same good reasons.

Make verifiable decision records a standard. If every AI-made change carried the same auditable chain from evidence to approval to outcome, regulators and insurers would have something concrete to examine. Whoever defines that format shapes the market.

Fund open benchmarks. Our memory research only became comparable to anyone else's because a public benchmark simulated a messy company at roughly 650M tokens. Korea could build the equivalent for manufacturing and telecom. Whoever builds the benchmark sets the research agenda.

Design provenance in from the start. Adding it afterwards is close to impossible.

On where to compete, I wouldn't chase the foundation model race. Korea's advantage is the density and quality of its industrial operations. Semiconductor fabs, shipyards, automotive plants, telecom networks and battery lines are causal systems where one wrong change costs millions an hour. Groups that own the full stack from factory floor to cloud are well placed to build world models of those systems, and outsiders will find that knowledge very hard to replicate.

My field is software. The same physics applies to a fab, and Korea runs the best in the world.

What It Means

Haque’s central argument is that enterprise AI needs a relationship layer connecting operational information. Such a layer could give agents a working model of dependencies, ownership and constraints, allowing them to assess the likely consequences of an action before it reaches a production system. It could also preserve knowledge that currently resides with experienced engineers and make it available across teams.

Decision Traces extend that structure into governance. A shared record connecting evidence, authority, verification, approval and outcomes would allow companies to review AI actions using concrete operational evidence. Permissions could then be expanded according to an agent’s performance on a particular system, while high-impact or irreversible actions remain under direct human control.

For Korea, the opportunity lies in applying these principles to industrial environments where operational knowledge has accumulated over decades. Semiconductor fabs, shipyards, battery plants, automotive production lines and telecommunications networks contain complex relationships that are difficult to reproduce from public datasets. Common definitions for services, owners, incidents and AI-generated changes could turn that experience into interoperable infrastructure and industry benchmarks.

This approach gives Korea a route into trusted industrial AI based on its existing production strengths. Building world models of industrial systems, recording AI decisions and validating results through open benchmarks would make operational experience transferable without giving up control of the underlying data. That combination could support safer automation at home and provide Korean companies with evidence they can present in global markets.

The final installment will connect the Korea Data Agency’s policy direction with DataStreams’ implementation experience, Jiahao Sun’s federated-learning model and Haque’s framework for operational context and accountability. It will examine how Korea can translate data quality, rights, interoperability, security and AI decision records into verifiable industrial results.

Korean version available here