When Evidence Changes, Approval Must Expire
A design for invalidating an agent recommendation when corrected evidence changes the decision it was built on.
At 10:00, a network planner approves a maintenance recommendation. The records show that a protected service has an independent backup route.
At 10:12, a corrected topology record arrives. The backup route has depended on the same component as the primary route since 09:30.
The approval should die at 10:12. It now authorises a change against evidence that the platform knows is wrong.
This is a design I have not yet proven in production. It is a discovery artifact for customer architects deciding whether an agent should support this class of operational decision. I do not have customer measurements for outage reduction, cost reduction or review time, so I make none of those claims here.
I use Enterprise Intelligence to mean a maintained account of business definitions, relationships, evidence and decision controls that people and agents can use for a specific decision. The platform must show what made a recommendation valid, detect when that basis changes and prevent an obsolete approval from reaching an operational system.
Treat approval as a claim over evidence
Consider a telecommunications operator preparing to take a network link out of service. The maintenance plan sits in one system, topology in another, active changes in a third and customer commitments in a fourth. An engineer reconciles those records before the change can proceed.
The recommendation needs to establish:
- which technical service and customer offering are affected;
- whether the primary and backup routes share equipment;
- whether another maintenance job overlaps the proposed window;
- which service commitment and policy apply; and
- whether the evidence is current enough for this decision.
If both routes pass through a component already scheduled for maintenance, the response should cite the topology and change records, explain the conflict and recommend deferral. If the dependency mapping is incomplete, it should stop. A missing relationship is not proof that no dependency exists.
The approval is therefore more than a user’s yes. It is a claim that a named command, target and time window remain acceptable under specific evidence and policy versions. The action controller must recheck that claim before execution. A changed target, expired window, superseded policy or invalidated evidence requires a new decision.
The recommendation carries its evidence and limits. Permission to execute comes later.
Keep four forms of knowledge distinguishable
The design separates four forms of knowledge because each earns authority differently.
| Form | Example in the maintenance decision | Evidence bar |
|---|---|---|
| Declared | An approved policy requires a protected service to retain an independent route. | Preserve the owner, version, effective dates and scope. |
| Observed | A topology record places both routes on a shared component. | Preserve the source, observation time, recorded time and freshness limit. |
| Inferred | The proposed change may interrupt both routes. | Show the input records, reasoning method and uncertainty. |
| Learned | Earlier change reviews suggest an additional dependency check. | Keep it as a candidate until an owner reviews its evidence and scope. |
These labels must survive retrieval and appear in the recommendation. They prevent a prediction from silently outranking policy or an unreviewed lesson from becoming a rule.
Different methods then do different jobs. Graph traversal finds recorded dependencies. Deterministic logic enforces the route-independence policy. A language model interprets the request and explains the result. An optimisation service can compare feasible maintenance windows after the evidence gate removes unsafe options.
This separation travels beyond telecommunications and beyond one technology stack. Declared, observed, inferred and learned knowledge recur in lending, supply chains, healthcare operations and industrial maintenance. The examples change. The evidence bars do not.
Build the smallest reusable knowledge product
The first knowledge product can be narrow: the dependencies and active constraints required to review this service change. It needs an owner, named sources, a version, access rules, freshness requirements and an explicit response when a source is stale or unavailable.
The vocabulary is equally bounded. The first model needs service, route, component, change window and commitment. It does not need a complete model of the operator.
Even this small vocabulary exposes ownership work. Operations may use service for a technical service while an account team uses it for a contracted customer offering. Treating them as one concept hides a relationship the decision needs. The model should represent both concepts, map them explicitly and name the owner of that mapping.
Systems of record retain authority. A corrected service commitment belongs in its owning system. The knowledge product carries the correction into dependent recommendations and decision records. It does not become a competing master.
The potential for reuse appears in the second workflow. Incident triage may need the same approved service identities and service-to-component relationships. It should consume the existing definitions and mappings under its own access and freshness rules instead of rebuilding them.
The reference work behind this post includes a read-only implementation candidate, not a production customer deployment. In that implementation, Microsoft Fabric holds shared semantics and analytical context, Azure Cosmos DB holds versioned operational knowledge products and decision records, and a Knowledge Gateway applies purpose, access and freshness checks.[1][3][4]
That split is an architecture choice, not the definition of Enterprise Intelligence. Another implementation can satisfy the same contracts with different graph, event and operational stores. Fabric ontology and Fabric IQ remain preview capabilities as of 9 September 2026, and the ontology documentation says upstream updates require refresh before they appear in the ontology item.[1][2] A design that depends on changing operational state must account for that boundary rather than assume that an ontology is a live decision record.
Preserve both kinds of time
Return to the 10:00 approval and the correction recorded at 10:12.
The corrected relationship became valid in the network at 09:30, but the platform did not record it until 10:12. A later query against only the latest topology would make the 10:00 recommendation look negligent. A query against only the 10:00 snapshot would miss the fact that its approval is now unsafe.
A bitemporal record preserves both:[5]
| Time axis | Question it answers |
|---|---|
| Valid time | When did this relationship apply in the network? |
| Recorded time | When did the platform know about it? |
The decision journal also preserves the exact evidence, policy and reasoning versions used at 10:00. A reviewer can reconstruct why the recommendation was reasonable from the platform’s recorded knowledge at that moment.
The 10:12 correction then triggers a new assessment of every pending recommendation that depended on the old route relationship. The platform keeps the earlier recommendation for audit, marks its evidence as superseded and invalidates its approval token. Historical explainability and present safety require both records.
This creates retention and privacy obligations. The operator must define how long decision evidence remains available, who can inspect it and how corrections or deletions propagate through the journal. Keeping every record forever is not a governance policy.
Separate recommendation, approval, execution and learning
The first deployment stays read-only. It identifies a shared dependency, recommends deferral or asks an engineer to resolve missing evidence. It cannot change the network.
Execution adds a separate action controller. The reasoning agent proposes; an authorised person approves; the controller checks the command, target, conditions, evidence version and expiry; the operational system executes. The controller rejects any mismatch instead of asking the model whether the old approval is still close enough.
Learning needs the same separation. A successful change can produce a candidate lesson, but it cannot approve that lesson. A reviewer must establish what happened, whether the action plausibly contributed, where the lesson applies and what evidence would contradict it. An approved lesson becomes a new version with an owner and source. An inconclusive outcome remains inconclusive.
A successful outcome can prompt a review. It cannot approve its own lesson.
Measure the existing decision before claiming benefit
This design needs observed baselines from a real environment. The fictional operator cannot supply them.
Before a pilot, the team should measure the existing process:
| Baseline | What to record |
|---|---|
| Reconciliation burden | Number of source systems and manual handoffs used for each decision. |
| Review time | Median and 90th-percentile minutes from request to a reviewable disposition. |
| Decision volume | Change approvals reviewed per week. |
| Evidence volatility | Corrections that arrive between recommendation, approval and execution. |
| Conflict detection | Known dependency or policy conflicts found and missed. |
| Abstention quality | Correct stops, needless stops and recommendations made with insufficient evidence. |
The pilot should use representative cases: an independent route, a shared dependency, an overlapping change, an unresolved service identity, stale topology, a late correction and a caller without permission to see the affected service. An engineer defines the expected disposition and supporting evidence for each case before the system runs.
Those results can support claims about review time, evidence completeness, conflict detection and inappropriate recommendations. They cannot establish outage or cost reduction without a longer operational study. Until the baseline cells contain observed values, this remains architecture as hypothesis.
The cost comparison must include source integration, definition ownership, runtime services and the human work of resolving exceptions. If a maintained query and runbook solve the decision reliably, they are the better design.
Before enabling action, replay the late-correction case. Show the evidence recorded at 10:00. Apply the correction recorded at 10:12 and valid from 09:30. Show every pending recommendation that depended on the old relationship. Then attempt execution with the old approval. The action controller must reject it.