Toward a self-improving context platform

Declared knowledge drifts

Enterprise context has traditionally been declared. A catalog defines business terminology, a semantic layer organizes metrics and maps them to data, and an ontology describes the concepts and relationships that matter to the business. Yet most of what an organization knows about its data is created through daily work, in queries, transformations, dashboards, models, and operational workflows. Making that knowledge available to AI agents has generally meant capturing it by hand in a context platform that records what data means, who owns it, and how it may be used.

Our hypothesis at Euno is that the maintenance burden this creates is structural rather than a matter of discipline. Declared context begins to diverge from reality as soon as the organization changes, at a rate set by how quickly the organization evolves. Increasing the review cadence slows that divergence without bounding it, because a reviewer is reconstructing by hand a picture the environment is already producing on its own.

In short: Neither the human element of periodic review nor the cadence itself is sufficient.

Derived and curated

Two kinds of context sit in every enterprise data environment. Technical context (metadata, lineage, usage, semantic definitions) can increasingly be reconstructed automatically from across the data environment, spanning data platforms, transformation systems, quality and security tooling, business intelligence (BI), and more. Institutional knowledge still has to be built on top of it: domain-specific terminology, rules for what can be trusted and what belongs to which domain, and instructions for when one source or one piece of business logic should be preferred, or trusted enough to act on.

That knowledge is what gives an agent the organizational understanding to make reliable decisions and act within the rules of the organization. For a handful of workflows it can be written and maintained by hand. As AI expands across domains, systems, and agents, the volume of institutional knowledge that must be captured and kept current grows past what manual curation supports.

The industry has long treated these two kinds as having different economics. Technical context is derived. Catalogs and lineage tools crawl, parse, and profile, and nobody expects an engineer to hand-write a column-level dependency graph. Institutional knowledge is curated. It arrives through a glossary someone fills in, a stewardship program, a certification workflow or a domain model drawn on a whiteboard. That division is rarely stated as a design decision because it has looked like a property of the material itself: one kind is mechanically recoverable, the other exists only in people's heads until someone writes it down.

Our research questions the second half of that and asks how much institutional knowledge can be inferred from operational signals rather than curated out of band, and how the remainder can be maintained with the least human effort. Two developments have prompted this research. The first is the breadth of signal available. Connecting transformation, quality, security, access, BI, and collaboration systems rather than a warehouse alone produces evidence about meaning and trust that no single system holds. The second is that models can now read the resources themselves. A query, a dashboard title, a test assertion, a pull request description, and a deprecation notice are statements about what data means and how it should be used, not just structure to be parsed.

The question is therefore not whether institutional knowledge can be derived in principle, but how far the derivation reaches and where curation remains necessary.

The answer shapes what the platform can do without a human. Knowledge that can be observed should be observed. Knowledge that cannot should be cheap to state, easy to inspect, and continuously checked against the evidence.

Observed

Much of what determines which data an organization uses and trusts is encoded in patterns across the metadata graph rather than in any single authoritative declaration. Individually the signals are weak. A transformation, a join, a certification, an access grant, or a deprecation each says something about meaning, trust, and intended use, and each can mislead on its own. Considered together they corroborate one another, and the combination supports inferences that no single signal would justify.

Institutional knowledge makes two kinds of claim, and the distinction between them determines how far derivation can go:

• Some are descriptive. Ownership, domain membership, and lineage-based provenance are facts about the organization that the environment already records in several places at once. Where the signals disagree, the disagreement is informative rather than blocking: conflicting ownership evidence usually means ownership is genuinely contested, which is worth surfacing.
• Some are normative. Which source should be preferred, what may be acted on without review, and what a term ought to mean are judgments. Usage patterns reveal what is currently preferred, which is not the same as what should be preferred. A governance layer exists partly to override current practice, so a system that infers policy from behavior will ratify exactly the habits an organization is trying to correct.

Trustworthiness sits between the two. Freshness, test coverage, incident history, and certification are observable; the threshold at which those add up to "trusted enough to act on" is a decision.

We therefore treat the two differently. Descriptive knowledge is derived and maintained automatically, with human review reserved for conflicts. Normative knowledge is not inferred but evidenced: the platform assembles the operational case for a proposed rule or preference and puts it in front of the person who has the authority to set it. This is also the principle that governs the boundary between automatic and human, which the platform would otherwise have to resolve case by case.

Because these patterns are regenerated continuously, they also register organizational change. Shifts in how the organization works appear in the signals before anyone documents them, which makes the graph a detector for stale declared knowledge as well as a source of derived knowledge.

Explicit

Derived knowledge is only useful if a person can still repair it, and repair is why explicitness matters.

The knowledge the platform holds stays as readable artifacts: statements a person or agent can open, trace to the signals that produced them, and edit. This is not explainability in the sense the interpretability literature uses, where a rationale is generated after the fact for the output of an opaque model. There is no opaque model to rationalize. The artifact is the record, and it is written in a form meant to be read.

Correction has to be local. A person who disagrees with one domain assignment needs to change that assignment without altering unrelated behavior, and needs to see what else the change touches before committing to it. Representations that fold knowledge into model weights or into a single large prompt fail this test: effects cannot be anticipated, corrections cannot be scoped, and every repair risks a regression somewhere the author was not looking. Inferred knowledge that cannot be inspected and corrected is harder to trust than the declared knowledge it replaces.

Provenance is part of the same requirement. Each derived statement carries the evidence behind it, so a reviewer can judge whether the inference was sound rather than only whether the conclusion feels right.

Evaluated

A platform that changes its own context needs a way to tell whether a change helped. Without one, derivation is unfalsifiable and every proposed update needs a human, which is the cost the platform exists to remove. What to measure with is part of the research problem rather than a prerequisite for it, so we began from the requirements an expert evaluator would have to meet.

• Reproducible. Running the evaluator twice against unchanged context has to produce the same result, or a difference in score cannot be attributed to a change in the knowledge.
• Self-maintaining. It has to be derivable from signals the organization already produces and cheap enough to run continuously, since an evaluator assembled by hand drifts the way declared context drifts, which relocates the maintenance problem rather than solving it.
• Faithful. A higher score must correspond to context that serves people and agents better, rather than to context better fitted to the instrument.
• Sensitive. A real change in quality has to move the score. The absolute level carries little information on its own; the movement between successive runs is what supports a decision.

The evaluator we arrived at is a set of questions per domain, each paired with the resources in which its answer should be found. A run opens a fresh agent session, submits the question as a user would, and compares the resources the agent retrieves against the expected set.

What it scores is retrieval rather than answers: a natural-language answer is the joint product of the context and the model, so grading answers measures both at once and cannot separate a context failure from a reasoning failure. The resources an agent reaches for are the direct expression of what the context told it to trust and where to look, which is what institutional knowledge exists to determine. Comparing two sets of resource identifiers is also an exact operation, so the scoring step contributes no variance of its own and precision and recall are defined without a rubric.

Why this shape for the evaluator satisfies the reproducibility, faithfulness, and sensitivity requirements is self-explanatory. Self-maintenance is based on new signals that are collected continuously: what users and agents are actually asking. By comparing the questions being asked with the existing set of evaluation questions, we are able to identify coverage gaps, which we fill by authoring new questions, along with questions that are no longer relevant and can be removed.

Two consequences follow from the shape of the evaluator. More questions are better than fewer, since coverage is what bounds the score. And a set per domain beats one mixed set, because a domain-scoped score localizes a regression to the knowledge that produced it, which is the property that localizes a regression to the knowledge that produced it, giving the measurement the same locality that makes the knowledge correctable.

The loop

The three properties of observed, explicit, and evaluated describe an artifact; the platform runs a cycle over it. Signals produce a derived statement. The statement is inspectable and correctable, so a human can intervene at any point. Evaluation scores the current context against usage. Revision proposes a change, which becomes new evidence for the next pass. Agent interactions feed the same loop, so the guidance improves as the organization uses it.

Each property depends on the others. Derived knowledge that is not explicit cannot be inspected or repaired. Explicit knowledge without evaluation cannot be systematically improved. Evaluation without continuous derivation tells you only how far a declared representation has drifted, which is a diagnosis rather than a remedy.

AI-assisted software development is the closest precedent for delegating substantial work to agents while keeping the result reliable, and it has the same shape. Quality is measurable, so "is this change good?" has a reproducible answer. Measurement lets an agent close its own loop: propose, test, observe, revise, without a human adjudicating each iteration. And the artifact stays explicit. Code may be derived from a prompt, but the code is the record. It can be inspected, diffed, tested, and edited line by line, and nobody discards it to regenerate the application from its original intent whenever something changes.

The analogy has a limit worth stating. A test suite is written by humans and is itself the specification, so correctness in software is exogenous to the code. Evaluation derived from usage is closer to generating tests from production traffic: it catches regressions reliably and cannot tell you the specification was wrong.

Where humans stay

The objective is not to remove people from the loop but to spend their judgment where it establishes and preserves trust: resolving ambiguity, setting and validating organizational boundaries, reviewing consequential changes, and deciding when the evidence is insufficient. Setting normative knowledge belongs here by construction, since no volume of operational signal settles what an organization should prefer. Detecting change, proposing updates, evaluating their effect, and maintaining what is already established can increasingly be delegated to agents.

Success is therefore not measured by how few humans remain, but by whether the attention they owe the system stays flat as the number of agents, domains, and workflows grows.

The open questions concern where that boundary sits. Which signals justify updating which forms of knowledge automatically. Which measures are reliable enough to guide revision without supervision. Which changes need human validation regardless of how strong the evidence looks. And how those boundaries should move as evidence accumulates.