5 Data and information architecture

This chapter explains that data architecture is not just about storing source records; in autonomous systems it becomes the information-control layer that determines what an agent can see, trust, transform, retain, and act on. Using a legal dispute to illustrate the risks, it shows how plausible but unverified information can gain authority as it moves through human review, retrieval, summaries, and agent workflows, making provenance, evidential status, applicability, and accountability essential before any information is treated as authoritative.

To manage that risk, the chapter introduces a set of connected patterns for governing context. Trusted Context defines what information is fit for a specific purpose and authority level; Enterprise Retrieval-Augmented Generation controls how candidate knowledge enters the agent’s working view; the Enterprise Knowledge Graph preserves governed meaning and relationships; the Context Graph captures the live decision episode; and Policy as Data, backed by pre-agent guardrails, ensures that institutional rules are machine-evaluable before information shapes action. Across these patterns, the chapter emphasizes that relevance is not the same as authority, and that context must be qualified, versioned, and bounded by policy.

The chapter also extends traditional data quality concerns into agentic use. Accuracy, completeness, timeliness, consistency, traceability, privacy, confidentiality, and compliance all become control requirements because weak or stale data can directly influence recommendations, disclosures, and actions. It closes with common anti-patterns such as detached context, ungoverned derived data, policy trapped in prompts, and logs that cannot reconstruct decisions, then offers an implementation playbook for operationalizing the architecture through authority decisions, governed retrieval, policy enforcement, continuity controls, and reconstruction-ready traces.

Agentic influence on the traditional data lifecycle stages

Agentic effect on horizontal cross-cutting control dimensions

Context supply paths into the agentic runtime.

Simplified Enterprise Knowledge Graph for commercial contract law.

‎Figure 5.5 How Enterprise RAG, the Enterprise Knowledge Graph, and Trusted Context work together

Context Graph for a live commercial contract decision episode.

• Treat data architecture as part of the autonomy control system. Once information shapes agent behavior, govern its context, interpretations, derived artifacts, policy state, and trace.
• Extend lifecycle and horizontal controls into the agentic runtime. Ownership, classification, quality, lineage, privacy, retention, and policy must survive retrieval, transformation, memory, tool use, and reuse.
• Use Trusted Context to determine what the agent may rely on for a specific purpose, decision surface, and authority level.
• Govern Enterprise RAG as a knowledge-supply path. Retrieval must preserve authority, permission, version, applicability, freshness, and traceability, not merely relevance.
• Keep raw evidence, extracted representations, interpretations, factual propositions, and conclusions distinct, particularly when processing multimodal information.
• Use the Knowledge Graph to preserve reusable enterprise meaning and the Context Graph to reconstruct what shaped a particular decision episode.
• Represent policy as governed data and enforce material boundaries independently of the model before information enters context, memory, tools, or external outputs.
• Tie the agent’s authority to information quality. If required information is missing, stale, uncertain, unauthorized, or conflicting, reduce what the agent may do and require refresh, corroboration, review, or escalation.
• Recognize anti-patterns that break information continuity. Watch for context detached from source state, derived information that loses inherited obligations, relevance mistaken for authority, policy left to the model, and traces that cannot reconstruct the decision.
• Use the implementation playbook to put the architecture into operation. Carry the chapter’s patterns into runtime components, interfaces, tests, change handling, and control evidence.

FAQ