When Evidence Changes, Permission to Act Must Expire
A design for binding agent-assisted execution approval to the evidence, policy and target that made it valid.
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 old approval cannot survive that correction. Once the platform records the new topology, the action controller must reject the approved change until someone reviews it again.
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. A CMDB, event log, policy engine and authorisation service can implement the pattern. The Enterprise Intelligence layer earns its keep when a second workflow reuses the same definitions, evidence lineage and decision contracts.
For this maintenance decision, the platform must show what made the recommendation valid, detect when that basis changes and prevent obsolete permission from reaching the network.
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.
Approval is a claim that a named command, target and time window remain acceptable under specific evidence and policy versions. A user’s yes records that claim; it does not make the claim timeless. The action controller rechecks it immediately 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 compares feasible maintenance windows after the evidence gate removes unsafe options.
The same boundary works in a supplier-risk decision. An approved sourcing rule is declared. A delayed shipment is observed. A predicted production stoppage is inferred. A proposed exception from an earlier disruption is learned and still requires review. Each form keeps its own evidence bar.
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 reuse claim begins with 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. If it cannot, the first project produced an application data model rather than shared enterprise intelligence.
One Microsoft implementation can use Fabric for shared semantics and analytical context, and Azure Cosmos DB for versioned operational knowledge products and decision records.[1][3][4]
The product documentation supports those storage and semantic capabilities. It does not provide the evidence manifest, decision journal, reverse dependency index, approval token or invalidation control described here. Those are application contracts.
Another implementation can satisfy the contracts with different graph, event and operational stores. Fabric ontology and Fabric IQ remain preview capabilities as of 12 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 treat an ontology as 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.
Every recommendation carries an evidence manifest. The manifest names each source record and version, its valid and recorded times, the policy version, the target, the proposed command and the method that produced the disposition. If a model extracts a fact or makes an inference that affects the decision, the manifest also records that model step and its output. A model used only to explain a deterministic result does not become decision evidence.
The correction path has four steps:
- Append the corrected topology version and a correction event. Do not overwrite the record used at 10:00.
- Use a reverse dependency index to find pending recommendations whose evidence manifests reference the superseded topology version.
- Mark those recommendations stale, increment their decision generation and revoke approval tokens bound to the old evidence digest.
- Let the action controller consume a token only when its target, evidence digest and decision generation still match the current journal state.
The conditional check closes the race inside the controller. It does not close the gap between the controller and an external network system. A stronger design sends the decision generation as a fencing token and requires the operational adapter to reject an older generation. Where the target cannot enforce fencing, the design cannot promise that every late correction will stop an in-flight action. That residual window belongs in the approval conditions.
If the controller has not crossed the operational point of no return, it rejects the command. If execution has already started, invalidation becomes an incident signal and may trigger a compensating action; it cannot undo the past.
A later correction appends another version and runs the same assessment again. The journal never rewrites what the platform knew at 10:00 or 10:12.
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. |
| Evidence volatility | Corrections that arrive between recommendation, approval and execution. |
| Decision quality | Known conflicts found and missed, 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. A maintained query and runbook remain the better design when they solve the decision reliably.
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. Race the correction against the execution request on both sides of the conditional check. The old token must fail when invalidation commits first. A command already accepted behind the fencing boundary must follow the documented incident or compensation path.