Agentic systems in regulated domains need more than relevant text. A filing review may include an approved exhibit, a draft analyst summary, a prior objection letter, and meeting notes. The agent should not treat those sources as interchangeable. Context needs to carry meaning, authority, provenance, and explicit links before an agent uses it.

Contextbase and Source Graph provide that separation. Contextbase keeps organizational knowledge in governed, reviewable plain text. Source Graph gives it a buildable grammar for identity, type, relationships, and validation, then compiles it into an inspectable map. Agents can use the same grammar to explore existing knowledge and curate new knowledge into it. The architecture connects source material to the context used by apps and agents.

The Four-Layer Model

Contextbase provides the governed-source system and its source graph. Effective’s broader product architecture places that subsystem inside a four-layer organizational context model.

The Data Layer defines domain meaning through the Records framework and references operational data. Record definitions describe business objects, fields, relationships, provenance, lifecycle states, scopes, and constraints. Operational records remain in Cloud SQL and in the systems that own them: regulator portals, trial systems, claims platforms, market-data providers, warehouses, and document repositories.

The Context Layer is Contextbase and Vault. It stores and governs source artifacts: markdown, documents, evidence, SOPs, reports, decisions, workflow source, record definitions, and materializer declarations. Some Data Layer artifacts are authored in Contextbase. The Data Layer owns the domain meaning they define.

The Knowledge Layer is Source Graph. It maps governed source into semantic nodes and typed edges. It tells the system what each node is, who owns or governs it when that is declared, which record definitions it references, and what it connects to. Materializers can use that structure to produce projections for runtime surfaces.

The Session Layer is where people, agents, apps, workspaces, and Mission Control operate. At runtime, an agent host can assemble a scoped context bundle from multiple authorities: Source Graph node IDs and edges, cited source excerpts, record references, materialized projection records, IAM permission claims, workflow-state references, freshness rules, and unresolved diagnostics. Source Graph anchors the bundle. The surrounding runtime authorities supply their own claims.

This boundary matters. Source Graph is the governed graph that materializers and runtime systems can use.

The architecture keeps projection and enforcement separate. Materializers compile governed Source Graph changes into projections and diagnostics. Separate runtime authorities may consume those projections when enforcing policy, workflow, permissions, or agent-launch constraints.

Four-layer architecture: Data Layer, Context Layer, Knowledge Layer, and Session Layer, with runtime enforcement shown as a separate boundary.

A Grammar for Curated Context

Plain text makes organizational knowledge portable, reviewable, and easy to author. Skills and team wikis often add conventions for where content belongs and how pages should relate, but those conventions usually remain implicit. Humans supply the missing interpretation through familiarity with the repository.

When agents both explore and curate that knowledge at scale, small inconsistencies compound. Draft guidance can appear equivalent to approved guidance, generated summaries can lose their connection to evidence, duplicate pages can diverge, and plausible additions can land in the wrong place. This is a practical form of context poisoning: gradual degradation of the context environment until serious work can no longer rely on its structure.

Source Graph makes those conventions explicit and buildable. Identity, type, relationships, and validation rules give agents shared rails for reading and writing. Retrieval still finds relevant material; the grammar supplies the meaning around it: what each source represents, where it came from, and how it relates to associated knowledge.

For a personal-auto rate review, context may include a filed exhibit, claims analysis, a pricing decision, and meeting notes. The useful questions are:

  • What object does this source represent?
  • Who owns it?
  • Is it approved, draft, deprecated, generated, or archived?
  • Which facts does it author, and which facts does it merely cite?
  • Which record definitions does it reference?
  • Which workflows can use it?
  • Which downstream projections were built from it?
  • What should happen when it conflicts with another source?

When domain contracts model those roles, Source Graph preserves the declarations and relationships. Agents can follow the contracts while exploring the graph and while adding new knowledge. A runtime can then combine relevance with modeled authority, provenance, and context when assembling the review.

The Source-to-Runtime Lifecycle

A filing package moves from authored source to runtime context through five stages:

  1. Author. People and agents curate the filing package, exhibit, review notes, and related knowledge as governed source under a shared grammar.
  2. Compile. Source Graph assigns semantic identity and combines authored relationships with contract-bound inference.
  3. Validate. Type contracts and graph rules check that additions fit the expected structure and produce machine-readable diagnostics.
  4. Project. Materializers plan or compile representations for runtime systems.
  5. Assemble. An app or agent host combines scoped graph context with excerpts, permissions, workflow state, and other runtime claims.

The graph snapshot, indexes, diagnostics, manifest, and projection results make the lifecycle inspectable. The remaining sections walk through those boundaries.

Compiling Governed Source

A contextbase is a prose-first source tree identified by its root README.md. Markdown carries rationale, caveats, scope, and review notes; structured metadata makes that meaning compilable.

Source Graph separates physical paths from semantic nodes. A file or folder becomes semantic when it declares a source-graph.kind or inherits one through a parent child contract. From there, the compiler establishes four things:

  • Identity. A package, exhibit, report, or procedure can be referenced without depending on its display title. Instance IDs may be inferred from type and path or declared explicitly when they must survive a move.
  • Type. Node types and reusable traits define allowed metadata, required relationships, and folder layout.
  • Relationships. Authored edges declare software-significant connections. Visible rules infer outgoing-link@v1 from Markdown links and materialize incoming-link@v1 as the inverse edge on each local target.
  • Organization. Collections and child contracts type repeated source areas without duplicating frontmatter in every file.

A source tree and its graph

Consider a personal-auto Contextbase. The tree reflects familiar areas of organizational knowledge, while one California filing is expanded:

personal-auto/
├── README.md
├── types/
│   └── …
├── claims-intel/
│   ├── README.md
│   ├── severity-trends.md
│   └── …
├── meeting-notes/
│   ├── 2026-01-pricing-review.md
│   └── …
├── decisions/
│   ├── 2026-rate-action.md
│   └── …
└── filings/
    ├── …
    └── ca-2026-rate-revision/
        ├── README.md
        ├── rate-exhibit.md
        ├── actuarial-memo.md
        └── review.md

Local node types are defined under types/. Five representative files show how the source uses that vocabulary:

# personal-auto/README.md
---
source-graph:
  id: personal-auto
  kind: contextbase@v1
---

# filings/ca-2026-rate-revision/README.md
---
source-graph:
  id: filing-package:ca-2026-rate-revision
  kind: self:filing-package@v1
---

# claims-intel/severity-trends.md
---
source-graph:
  id: claims-intel:severity-trends
  kind: self:claims-intel@v1
---

# decisions/2026-rate-action.md
---
source-graph:
  id: decision:2026-rate-action
  kind: self:decision@v1
  edges:
    references@v1:
      - path: ../meeting-notes/2026-01-pricing-review.md
---

# filings/ca-2026-rate-revision/review.md
---
source-graph:
  id: filing-review:ca-2026-rate-revision
  kind: self:filing-review@v1
  edges:
    references@v1:
      - path: ./rate-exhibit.md
      - path: ./actuarial-memo.md
      - path: ../../claims-intel/severity-trends.md
      - path: ../../decisions/2026-rate-action.md
---

Suppose the filing package README also contains a normal Markdown link to review.md. Source Graph compiles a view that crosses the filesystem boundaries:

filing-package:ca-2026-rate-revision
    └── outgoing-link@v1 ──► filing-review:ca-2026-rate-revision
                              ├── references@v1 ──► rate-exhibit
                              ├── references@v1 ──► actuarial-memo
                              ├── references@v1 ──► claims-intel:severity-trends
                              └── references@v1 ──► decision:2026-rate-action
                                                    └── references@v1
                                                        ──► 2026-01-pricing-review

filing-package:ca-2026-rate-revision
    ◄── incoming-link@v1 ───── filing-review:ca-2026-rate-revision

The authored edges capture relationships across claims intelligence, decisions, meetings, and filings. The Markdown link produces an inferred outgoing-link@v1, with incoming-link@v1 materialized as its inverse on the local review target. An agent exploring the filing can follow that structure; an agent curating a new review uses the same types and relationship grammar to place it correctly.

Governed source artifacts connected through Source Graph to procedures, workflows, record definitions, and runtime surfaces.

Indexing Pipeline

The indexing pipeline is the boundary between governed source and compiled knowledge. It processes a source revision as a whole, so declarations, dependencies, identity, and relationships are resolved against one coherent snapshot rather than interpreted independently by every consumer.

The output is a revisioned graph with query indexes and diagnostics tied to the same source state. Materializer planning begins from that compiled view, giving projections common coordinates. The pipeline does not decide publication policy or runtime permissions; it makes source state inspectable and reproducible for the systems that do.

Governance and Review

Source changes can alter what apps and agents see, so review belongs around the source. Pull requests, approvals, deployment records, or audit systems can use graph identity, diagnostics, ownership, and materializer impact to make review precise. A root OWNERS file expresses path governance and is itself governed source.

Materializers and Projections

Materializers are the boundary between compiled knowledge and runtime systems. Starting from a revisioned graph, they select the relevant scope and translate it into resources shaped for a particular target. This keeps target-specific projection logic out of governed source and gives consumers a shared interpretation of the graph.

A projection is broader than a read model. It can contain resources that a target stores, executes, reconciles, or queries. Source Graph supplies the identity, relationships, diagnostics, and source revision; the materializer runner owns target-specific behavior. The resulting resources remain traceable to governed source without pulling runtime concerns into the source model.

Source Graph and Agents

One runtime assembly pattern gives an agent a scoped context bundle anchored by Source Graph. For the filing review, the package node is the semantic entrypoint. Scoped graph queries return its nodes, relationships, declarations, and diagnostics; the runtime assembles the rest.

The assembly path can then:

  • resolve the semantic node ID;
  • follow authored and inferred edges to the exhibit, report, procedure, workflow, and record references;
  • load declared metadata and modeled authority or ownership when present;
  • combine cited excerpts and projection records with permission and workflow claims supplied by runtime systems.

The model still reasons. It still synthesizes. It still writes. The input is a scoped bundle whose parts have roles.

A relevance-only answer might say:

I found a filing and drafted a response.

A governed answer says:

This response cites the approved filing exhibit, uses the current objection
letter, excludes a stale analyst summary, and requires product review before
submission.

In this architecture, the assembled context can carry citation, modeled authority, freshness, exclusion rationale, and review-state requirements. Source Graph itself does not assemble final-answer provenance.

Source Graph and Apps

Apps can query Source Graph and consume materialized projections.

A filing workbench can show which package nodes changed and which projections are affected. Search results can distinguish the filed exhibit from analyst synthesis. A review screen can expose modeled freshness and authority alongside the source.

This creates a path to keeping apps and agents aligned around the same governed identities. The Source Graph packages provide the graph, client, and query primitives; each product integration still decides which projections and runtime authorities it consumes.

The four-layer diagram captures this shape: sessions at the top, Source Graph as the Knowledge Layer, Contextbase as governed source, Data Layer record definitions and operational data below, and runtime enforcement shown as a separate boundary. Materializers provide the compiler boundary from governed source into runtime projections.

Apps and agents assemble scoped context around a shared Source Graph while policy and workflow enforcement remain separate.

Conflict Handling

Regulated work rarely fails from missing information. It fails when multiple sources disagree and the system lacks authority rules for action.

A filed rate exhibit may disagree with a later analyst report, while a generated summary may still reflect the earlier analysis.

Source Graph preserves the modeled metadata and relationships that a domain-specific resolver can use before synthesis. When the relevant properties are modeled through node-type schemas, traits, edges, OWNERS, review metadata, or projections, that resolver can compare authority, lifecycle state, scope, freshness, ownership, and relationships. It can say:

These sources disagree. This one is approved for this scope and time window.
This one is derived. This owner needs to resolve it.

Source Graph does not detect contradictory claims or choose an authoritative source by itself. Its built-in conflict diagnostics concern graph and contract structure: semantic-slot collisions, duplicate IDs, schema or required-edge conflicts, and materializer declaration conflicts. Content adjudication belongs to the modeled domain and runtime resolver.

Design Principles

Source first. Authored source owns governed meaning. Runtime resources can combine source-derived representations with operational state owned by the target system.

Relationships are explainable. Authored edges declare relationships explicitly. Inferred edges come from visible indexing rules such as Markdown links.

Exploration and curation share a grammar. Agents read and extend organizational knowledge through the same identities, types, relationships, and validation rules.

Derived resources remain traceable. Source-derived indexes, panels, summaries, and runtime records can be rebuilt. Target systems may maintain additional operational state alongside them.

Enforcement remains separate. Materializers compile projections. Runtime authorities decide permissions, policy, workflow behavior, and agent-launch constraints.

Closing

Source Graph makes organizational knowledge buildable. Contextbase keeps that knowledge in governed, reviewable plain text; Source Graph gives it identity, type, relationships, and validation; and compilation makes the result inspectable.

Because exploration and curation share the same grammar, people, apps, and agents can work from one evolving body of knowledge. Materializers produce traceable, target-ready resources. Runtime hosts retain operational control. Together, those boundaries provide a durable foundation for curated agent context.

We built Contextbase and Source Graph as infrastructure for governed agent context. The problems they address are not unique to Effective AI: source authority, provenance, graph structure, review state, and runtime assembly matter for any serious agent system. We are thinking about how this work could be useful to the broader agent-building community. If you are working on governed context, agent memory, or source-backed workflows and want to use it or help shape where it goes next, reach out.

All posts