The Standards Knowledge Graph turns governance documents into validated, versioned, queryable rules that agents can safely use.
When an agent needs to check an API standard, it should not scan through a 40-page Confluence document. Instead, AEGIS extracts the rules from that document, structures them as a graph of nodes and relationships, gets a domain expert to validate them, and publishes a versioned graph. The agent then queries only the relevant part of that graph — a precise, trusted answer in under 400 tokens.
Most AI systems send raw documents straight to a language model and hope it picks out the right answer. That is expensive, unreliable, and impossible to audit.
AEGIS does it differently. Source documents — Confluence pages, SharePoint files, meeting transcripts — are parsed by an agent that extracts entities, rules, and relationships. These become structured nodes and edges in a knowledge graph.
That draft graph then goes to a domain owner for validation. They review every rule for accuracy, intent, and completeness. When they approve it, the graph goes live and agents can query it.
When a standard changes — say, REST Y.0 replaces REST X.0 — the old rule is not deleted. It is marked as superseded and kept for audit. The new rule carries its source, confidence score, and approver. Agents always see the current, validated version.
Opening — the problem with raw documents (30 seconds)
In most enterprise AI deployments, agents receive raw documents as context. A governance agent might receive a 20,000-token policy document every time it answers a question. That is slow, expensive, and the agent may still get the answer wrong because it cannot distinguish a current rule from a superseded one buried three paragraphs down.
What a knowledge graph is (30 seconds)
A knowledge graph is a structured network. Instead of storing "the API standard is REST X.0" as a sentence in a document, we store it as a relationship: REST X.0 node — enforces edge — versioned endpoints node. That node also carries properties: status is Approved, confidence is 96%, owner is Architecture Governance, source is the API Standards document.
Now an agent can ask a precise question — "what is the current approved API standard?" — and get back a structured, evidence-linked answer in under 400 tokens.
How AEGIS builds the graph (45 seconds)
Step one: source documents — Confluence pages, SharePoint files, meeting transcripts — are parsed by the AEGIS ingestion agent. It identifies entities, rules, values, and the relationships between them.
Step two: a draft graph is created. Nodes, edges, and properties are written, but the graph is not yet queryable. Status is pending.
Step three: the draft goes to a domain owner — in this case, the Architecture Governance team. They review every rule. Is it accurate? Does it match the intent of the original standard? Are there conflicts? Do the versions look right? They can approve, reject, edit, or ask for clarification.
Step four: on approval, the graph goes live and agents can query it.
The REST X.0 to REST Y.0 example (45 seconds)
Here is a concrete example. The approved governance rule today says: "APIs must follow REST X.0." That rule lives in the graph with its source document, confidence score, and owner.
Now a meeting transcript arrives: "REST Y.0 has been agreed as the new API standard."
AEGIS detects the topic — API standard — using a keyword match, no LLM involved. It retrieves only the REST-related rules from the graph — not the full 9-rule knowledge base. It finds REST X.0, creates a REST Y.0 Candidate node linked to the transcript as evidence, and marks it as superseding REST X.0, pending validation.
The domain owner reviews and approves. REST Y.0 becomes active. REST X.0 is marked superseded. It stays in the graph, fully traceable — who approved it, when, which document it came from.
Closing — why this matters (30 seconds)
Agents always query the approved, current version of the standards graph — not raw documents. Every rule has a source, a confidence score, a named approver, and a version history. When something changes, the old rule is kept for audit. Nothing is silently deleted or overwritten.
That is the standard for enterprise-grade AI.
Q: Is this just RAG — retrieval-augmented generation?
No. RAG retrieves chunks of raw text based on semantic similarity. AEGIS retrieves structured, validated rules from a graph based on deterministic topic detection. RAG returns "here is a passage that mentions REST X.0." AEGIS returns "here is the current approved rule, its owner, its version, and its source evidence." They are fundamentally different — in precision, cost, and auditability.
Q: Why a graph rather than a database or a vector store?
A graph lets us represent relationships explicitly — REST Y.0 supersedes REST X.0, OAuth2 is required by REST X.0, REST X.0 conflicts with legacy push-based integration. A relational database can store facts but does not naturally represent these relationship chains. A vector store returns similar text but cannot reason about superseding, conflicts, or version lineage. The graph gives us structured traversal, not just similarity search.
Q: Who validates the graph? How much effort is that?
Domain owners validate the graph — the people who already own the standards. An Architecture Governance lead, a data protection officer, a security architect. The validation UI presents each extracted rule with its source evidence. The reviewer reads the rule, checks it against the source, and approves or rejects. For a standard of 9–15 rules, this takes 20–30 minutes initially. After that, only new or changed rules require review — the approved graph stays live.
Q: What happens when a standard changes?
The source document or transcript is re-ingested. A candidate update is created — the new rule linked to its evidence source. The candidate is sent to the domain owner. On approval, the new rule becomes active and the old rule is marked superseded. The old rule is never deleted. Agents always receive the current approved version. Nothing changes silently.
Q: How does this reduce hallucination?
Hallucination happens when a model guesses or interpolates because it lacks precise context. When AEGIS sends an agent a structured rule — REST X.0, Status: Approved, enforces OAuth2 authentication — the agent has no reason to guess. The answer is in the context. Validated, sourced, versioned. The graph is the single source of truth agents use, and it only contains rules that a human expert has reviewed and approved.
Q: How does this reduce token usage?
Full-document RAG might send 10,000–20,000 tokens of governance context to an agent for every query. AEGIS sends 400–1,500 tokens — the specific subgraph relevant to the question. In the REST example, instead of sending all 9 governance rules plus their source documents, the agent receives only the 1–2 REST-related rules. That is roughly 85–95% fewer tokens per agent call.
Q: How do agents actually use the graph?
Agents do not write queries directly. When a meeting transcript or new document arrives, AEGIS detects the topic using keyword matching — no LLM call. It traverses the relevant subgraph and builds a context slice of 400–1,500 tokens. That slice is passed to the agent as structured context. The agent then generates artifacts — user stories, ADRs, governance summaries — using only that validated, focused context.
Q: What happens to old rules?
Old rules are marked as superseded. They remain in the graph with their full provenance — original source document, approval date, approver name, confidence score, version number. Agents never receive superseded rules as active context, but the audit trail is always available. If a question arises about why a decision was made three months ago, the answer is in the graph.
Last updated: 2026 · Pranjal Patil · Capgemini