Context Is Situated, Authorized, Temporal, and Contestable
A working note on Contextual Data Architecture

A working note on Contextual Data Architecture

Context Is Situated, Authorized, Temporal, and Contestable

A working note on Contextual Data Architecture - Lovingly authored by a human and fact-checked, edited, and improved by AI.

Suppose a salesperson asks an AI to approve an unusual discount.

The AI searches the organization and finds almost exactly what we would hope it would find. It discovers a strategy post encouraging flexibility for important accounts. It finds the current price in the pricing system. It finds an authentic policy memo that once allowed a regional executive to approve a larger exception. It also finds a message from Finance objecting to the deal.

We might call this a retrieval success. The system found four pieces of information that are plainly relevant to the question.

And yet it still does not know what to do.

The strategy post may express a desirable direction without governing a single transaction. The pricing system may tell us the standard price while saying nothing about who can approve an exception. The policy memo may be authentic and may even have governed the decision last year, but it may no longer be in force. The Finance message may be an informal complaint, a warning from an accountable function, or evidence that the matter remains contested.

All four sources concern the same decision. They are not four interchangeable chunks of context.

This is where I think many of our current approaches to enterprise AI begin to break down. We have treated context as the material most semantically similar to the task. We retrieve it, rank it, compress it, and place it in front of a model. If the answer cites the retrieved material, we take some comfort that the system has grounded itself.

But grounded to what? A source can be relevant without being true. It can be true without being complete. It can be complete and still lack the authority to govern the decision in front of us. It can have governed yesterday and be obsolete today.

I want to propose a more demanding definition:

Context is not merely the information relevant to a task. It is the situated set of relationships among sources, assertions, identities, perspectives, time, authority, exclusions, decisions, and possible corrections.

I do not yet know if that definition is complete. I do think that each of those relationships can change what a system should be allowed to conclude or do. That gives us something architectural to test.

Three questions hiding inside one

For consequential work, we should separate at least three questions that our retrieval systems are tempted to collapse:

  1. Is this information relevant?
  2. Does it support the claim being made?
  3. May it govern this decision?

Relevance asks whether a source belongs in the candidate set. The strategy post, price calculation, delegation memo, and Finance objection all pass that test. Search, graph traversal, subscriptions, rules, and human judgment may each help us discover them. Discovery gives us an invitation to inspect. It does not give us permission to believe or act.

Support asks whether a particular source can bear the weight of a particular claim. The pricing system may strongly support the claim that the standard discount is ten percent. It may provide no support at all for the claim that a fifteen-percent discount is permitted. A strategy post may faithfully support the claim that one executive favored flexibility while providing weak support for a general policy that every salesperson may apply.

This means support belongs to the relationship between a source and a claim, not to a document in the abstract. A citation is useful because it tells us where a claim came from. It does not, by itself, establish that the source entails the claim, that the cited fragment is complete, that contrary evidence does not exist, or that the source has any authority over the decision.

Support does not always mean formal entailment. Depending on the claim and its consequence, the governing test may be deductive, probabilistic, corroborative, or explicitly human judgment. The architecture needs to identify which test applies and preserve its uncertainty; it does not get to turn semantic similarity into evidence merely because the model produces a score.

Authority asks the third question. Which identity, agreement, policy, role, or institution may legitimately control this commitment? The pricing system may govern product identity and standard price. A signed agreement may govern the customer’s contractual terms. A finance policy may govern exception authority. No one source needs to become the universal source of truth in order for each to govern the thing it is actually responsible for.

Authority does not magically make a record correct. Authoritative records can be incomplete, mistaken, corrupt, and in need of appeal. But a similar prior case, a plausible summary, or a confident model response cannot silently displace them. We need to know both what a source supports and what it is allowed to govern.

Could some low-consequence systems collapse these questions? Certainly. If I ask an AI to find the closest lunch menu, an elaborate authority model would be absurd. The burden should follow the consequence. The proposition here is not that every lookup needs a tribunal. It is that we should not use the convenience of low-stakes retrieval to design systems that make commitments for people and institutions.

Return to the discount

Let us make the example more difficult.

The current price calculation says ten percent. An authentic memo permits a regional executive to approve fifteen percent. A more recent governance notice may have withdrawn that delegation. Finance objects and claims that the old memo no longer governs. The strategy post tells the salesperson that the organization wants to be flexible with important accounts.

A relevance-first system may lead with the strategy post because its language most closely resembles the request. A source-link system may cite the old memo and appear carefully grounded. An authority-first system may notice that the memo was official and stop its investigation there.

Each system can still be wrong if the memo was authoritative when it was issued but is no longer effective when the discount must be approved.

What should the AI do? It does not automatically follow that the exception must be denied. Missing authority to approve is not authority to deny. The immediate safe result is smaller: do not commit the exception, preserve the conflict, and route the unresolved question to the function that currently governs discount authority. Once that authority is resolved, record the decision, the sources that justified it, the objection that remained, and the condition that should cause the decision to be reopened.

Abstention is not a failure when a worker lacks what is necessary to commit, provided the surrounding workflow defines the safe state, the responsible route, and what happens if no one resolves it. An unhandled abstention is a workflow failure. A useful refusal preserves the unresolved work without making the commitment and shows someone how to move it forward.

Context lives in more than one time

Enterprise records often receive one timestamp and are then asked to perform several incompatible jobs. At minimum, we sometimes need to know when a system observed a source and when that source was actually effective.

The old delegation memo may be observed today and have governed last year. A correction recorded tomorrow may apply retroactively. The newest file may tell us what governs now while telling us nothing about what governed a decision made six months ago.

This matters in two directions. To act now, the worker needs the authority effective now. To reconstruct a past decision, the reviewer needs to know what was both observable and governing then. If we substitute today’s state for the historical one, we make the organization appear to have known things it did not know and to have followed rules that did not yet exist.

Not every record needs a complete bitemporal implementation. Again, the burden should follow the consequence. But whenever time can change the legitimate action, “latest” is an inadequate theory of context.

Context belongs to a perspective

The salesperson sees a relationship and a revenue opportunity. Finance sees margin, policy, and precedent. Legal may see contractual language. The customer sees a promise and an expectation.

We should resist the urge to describe these as biased copies of one neutral context. Each participant has different duties, access, exposure, and authority. A meeting transcript does not become an approved fact merely because everyone spoke into the same recorder. Five model personas do not become five independent institutions merely because we gave them different names.

Perspective also determines what may be seen. Information relevant to Finance may be prohibited from the sales worker. Evidence available to an investigator may not be legitimate training material. Access for one purpose does not grant reuse for another.

The goal cannot be to collect every private thought. That would create a surveillance system in the name of context. We need to preserve only the perspectives that other people and systems are entitled to inspect and that could materially change the work.

Decisions do not erase disagreement

Organizations have to act before everyone agrees. That does not require them to manufacture unanimity after the fact.

If Finance objects to the pricing exception, the objection may not carry a veto. The authorized decision maker may approve the deal anyway. A durable account should still preserve the scope of the disagreement, the evidence offered, the protected role that raised it, the way the decision maker disposed of it, and the condition under which it should matter again.

Why preserve a losing argument? Because the outcome may later vindicate it. It may also reveal that the objection was unfounded or that everyone was asking the wrong question. If the system retains only the final value, it cannot learn which judgment needs refinement.

This does not mean that every preference should become immortal procedural debris. Contestability creates costs and can expose dissenters to retaliation. It needs scope, access, and eventual disposition. We preserve material disagreement so that a decision can remain decisive without pretending it has become eternally correct.

Absence is also situated

Suppose the current authority is not in the context supplied to the AI. Why is it absent?

Perhaps no source was found. Perhaps a governing source exists but is stale or disputed. Perhaps the information was deliberately excluded for privacy or security. Perhaps this worker lacks permission to use it. Perhaps the context budget forced an omission. Perhaps the question remains unresolved inside the institution itself.

These are not the same condition. An exclusion is a decision or prohibition. A deficiency is something required that remains missing or unsafe. A capacity omission is a transformation choice. None should silently become “not relevant.”

We cannot document the absence of everything. That would recreate the very burden we are trying to escape. We should record an absence when it could change interpretation, authority, commitment, remedy, or later learning.

We will never have all the context

At this point we encounter a harder problem than retrieval.

Even if the organization could locate every relevant source, the AI cannot keep all of it present for every task. Some of it should not be disclosed. Some of it will not fit. Some will be stale before the work finishes. A summary can help, but a summary is a new inference. Compression cannot remain perfectly isomorphic to the situation it compresses.

The answer, I suspect, is not one enormous context object. Nor is it a more clever universal truth score. We may need to stage context through the work.

Imagine that each stage receives the local detail needed to answer one bounded question. Alongside that local context travels a much smaller throughline envelope: the purpose of the work, the authority that governs it, the sources and prior decisions on which it depends, the material exclusions, the unresolved deficiencies, and a receipt for what the previous stage changed or left behind.

The first gate may identify candidate sources. The next may evaluate which claims they actually support. Another may resolve governing authority and effective time. A proposal gate may construct a possible action. An evaluation gate may test it. Only then does a commitment gate allow the organization to act.

Each step is lossy. The architecture does not become trustworthy by denying that fact. It becomes more trustworthy when the loss is declared, the throughline is tested at every handoff, and a deficiency can send the work back to fuller or more authoritative context.

This is still a working proposition. The complete joined loop belongs in the next article, and it will need to survive actual implementation. For now the important point is that context may be less like a payload we retrieve and more like a governed thread we preserve through a sequence of transformations.

What kind of thing are we building?

The emerging form is a task-shaped account whose parts remain addressable without forcing the reader to speak in schemas:

  • this source supports this assertion over this span;
  • this actor supplied this perspective;
  • this record governs this identity or policy for this effective period;
  • this inference remains uncertain;
  • this material was excluded for this purpose;
  • this objection remains attached to this decision;
  • this authority permitted this commitment;
  • this transformation omitted these things;
  • this correction changed these later uses.

The prose explanation should remain humane and readable. Beneath it, the relationships need to be explicit enough for a system to inspect, compile, test, and correct.

Different domains will realize these relationships differently. Existing applications and disciplined process may be enough in one place. Another may need schemas, events, graphs, policy engines, or shared services. I am not proposing one enterprise ontology, one repository, or an omniscient architect. Conceptual integrity should be able to survive federated custody and replaceable tools.

The test is not whether we can draw the perfect model. The test is whether the meaning survives the seams where one person, system, or agent hands work to another.

When interpretation becomes capital

If we resolve the pricing exception well, the work can leave something behind: a corrected source, a scoped rule, a clearer authority grant, a regression test, an explicit exception path, or a reopen condition tied to an observed outcome.

This is one way software converts labor into capital. The organization should not have to purchase the same investigation every time the situation recurs. Good interpretation can become durable infrastructure.

But durability amplifies error as readily as knowledge. A reusable rule that has lost its authority, effective period, scope, dissent, or correction path is not accumulated intelligence. It is accumulated confidence detached from its grounds.

The economic promise of contextual architecture therefore depends on the governance of reuse. We want judgment to compound. We do not want mistakes to compound invisibly.

A working proposition

I am proposing that relevance, support, and authority remain separate in the architecture of consequential work. Time, perspective, contestability, exclusion, and correction determine how those questions should be answered. Because no worker can carry all context, I am also proposing that context move through bounded transformations with a preserved throughline rather than be treated as one perfectly retrieved payload.

I am not yet claiming that this vocabulary is complete or that it establishes Contextual Data Architecture as a distinct discipline. It may prove to be a useful way of joining established practices in data governance, knowledge management, information architecture, software reliability, security, and organizational design. It may also expose a responsibility that has fallen between them.

The distinction earns its keep only when it changes design or prevents a material mistake.

I would particularly value disagreement on these questions:

  1. Where can relevance, support, and authority safely collapse without changing a consequential decision?
  2. What must remain in a throughline envelope for intent to survive a lossy transformation?
  3. How can we test whether a staged context process preserved meaning rather than merely preserving its own paperwork?
  4. When governing sources conflict, what responsibility belongs to the architecture and what remains institutional governance?
  5. Where does preserving dissent improve later decisions, and where does it merely create noise, retaliation risk, or procedural drag?
  6. Which important kind of context is missing from this account?

The next working note will examine the join itself: how context moves from capture and custody through assembly, proposal, evaluation, commitment, and outcome without pretending that any one stage can see the whole.

AI-STRATEGY
contextual-architecture contextual-data-architecture enterprise-ai ai-governance decision-intelligence thought-leadership