What Should a Twin Learn From a Mistake?

Imagine a consultancy preparing to chase an overdue invoice.

The accounting system shows that payment is late. The project system says the work is complete. The customer record contains the billing contact. An assistant using these records drafts a reminder.

But the account director knows that the client requested a change to the final deliverable. That change introduced a new approval requirement. The original sign-off covered the earlier scope, and its approver no longer has authority over the revised work.

The assistant retrieves the relevant messages and recommends clarifying acceptance before sending the reminder. That is useful. The more interesting question is what it learns for next time.

Keeping a copy of the conversation would preserve the incident. A better lesson would change what the system checks:

When a material scope change is linked to a milestone, establish whether the recorded acceptance covers the current scope before recommending the next collection step.

The invoice may still be overdue under its payment terms. What changes is the recommendation about how to handle it. The system has learned a missing question, not rewritten an accounting fact.

This is a proposal for how a Twin could improve through experience. The learning loop described here is a direction to explore, not a shipped MLX capability.

Learn Which Question Was Missing

“Check approval before chasing this customer” would be a narrow lesson. “Check approval before chasing every invoice” could burden routine work with unnecessary checks.

The useful change depends on what went wrong. Was the scope revision disconnected from the invoice? Did the assistant confuse delivery with acceptance? Did it find an approval without establishing what that approval covered?

Those failures require different repairs. Another instruction to “be careful” would leave the ambiguity intact.

For this case, the proposed repair is a relationship: acceptance must be connected to the scope version it covers. That gives the assistant a specific information requirement and, when evidence is missing, a specific question for the account owner.

A missing record is still a gap, not proof of a negative. “Acceptance not established from available evidence” is different from “the client has not accepted”. The assistant should preserve that uncertainty rather than turn a failed search into a business fact.

This is the most promising part of self-evolving context: experience could improve the questions a system knows to ask, as well as the answers it can retrieve.

Three Different Things Can Change

A graph is a way to represent things and their relationships: an invoice refers to a milestone; a milestone covers a scope of work; an approval applies to a particular version. Updating those records does not necessarily mean the system has learned anything.

I would separate three kinds of change:

• State: a milestone awaiting approval has now been accepted. A new fact updates the business record.
• Representation: delivery completion and acceptance were being treated as equivalent. The model needs separate concepts and an explicit link between acceptance and scope.
• Guidance: for changed milestones, establish whether acceptance covers the current version before recommending a collection step.

The latter two change how the system understands the work. They need more scrutiny than recording a new event, because they may affect future decisions across multiple cases.

This also gives us a better measure of progress than graph size. Adding thousands of nodes may only add data. Separating two confused concepts might improve a decision with very little new information. Learning could even make the graph smaller by merging duplicates or retiring unsupported inferences.

Graph-based retrieval provides part of the foundation. Microsoft's GraphRAG combines extraction, network analysis and summarisation to answer questions across connected information. Retrieving those connections and learning to revise them are different problems.

The preprint Procedural Graphs: Self-Evolving Execution Structures for LLM Agents, by Lu and colleagues, explores the second problem for agent procedures. Its graph guides action selection but remains fixed during each task. Between batches, a refiner proposes edits from execution feedback; validation determines which are retained. The guidance is advisory, rather than an execution constraint.

That is evidence about revisable procedures in the paper's experiments. Applying the idea to business relationships, obligations and information requirements is the extension proposed here. It needs its own evaluation.

Follow the Decision Across Systems

An application's boundary rarely contains the whole decision.

The project system describes delivery. A contract records obligations. Messages capture a scope change. The accounting system records the invoice. The question spans them: should someone chase payment, resolve acceptance, correct the invoice or ask for clarification?

The relevant context should follow those dependencies. For our example, that means connecting the invoice, milestone, current scope, acceptance evidence and authorised approver. Loading the customer's entire history would introduce unnecessary cost and potentially unrelated sensitive material.

There are existing foundations for this modelling. OCEL 2.0 represents events connected to business objects, relationships between objects and changes to their attributes. A proposed learning system could build on that work rather than inventing an event model from scratch.

The additional task is to identify which relationships matter to the decision at hand. Retrieval should stop at a useful boundary, shaped by relevance, access permissions and cost. When the necessary evidence is unavailable, the recommendation should expose the gap.

For the Twin, the practical opportunity is to make a recurring failure produce an inspectable correction to business context. “The assistant knows more about this customer” is too vague. “It now distinguishes acceptance of the original scope from acceptance of the revised scope” describes a change someone can assess.

Keep the Evidence Attached

An email says the client approved the work. The assistant interprets that as acceptance. A manager confirms the interpretation. Company policy permits the next step once the acceptance requirement is met.

These statements have different authority. A learning process must keep them distinguishable.

The source statement should retain its source. An inference should identify its evidence and assumptions. A human confirmation should record who supplied it and what it covers. Policy needs an accountable owner and a version.

The W3C PROV family provides a vocabulary for describing how information was produced, attributed and derived. Here, that history would support correction as well as citation.

Suppose an email turns out to approve only the original deliverable. The system should be able to find the acceptance inference that relied on it, the recommendation that followed, and any candidate lesson derived from the case. Correcting one source may require reconsidering several conclusions.

It should also recognise shared origins. An email, a meeting summary quoting it and an AI account note based on that summary are not three independent confirmations. Re-ingesting the assistant's own output must not make its earlier assumption look better supported.

Knowing whether a conclusion rests on a signed document, a second-hand comment or a disputed interpretation is more useful than an unexplained confidence score.

Test the Lesson Before Keeping It

Suppose the invoice is paid after the account director clarifies acceptance. We have observed a sequence, but we have not established how much the intervention helped. Payment might already have been scheduled.

That distinction matters if outcomes drive learning. Microsoft's EconML examples illustrate how differences between groups can make simple outcome comparisons misleading. A favourable result should trigger investigation rather than automatically validate the preceding recommendation.

I would test candidate changes in stages. Historical cases could check whether the revised model catches the missing dependency and avoids regressions. Each case must use only evidence available at the original decision time. Later knowledge would otherwise make the new approach look artificially capable.

Shadow operation could compare recommendations with real decisions while leaving action with people. It could reveal irrelevant checks, useful disagreements and human effort. It would not establish what would have happened if a different recommendation had been followed.

Where appropriate, prospective controlled trials could test effects on outcomes. Where that is impractical, the claim should remain narrower: the change identified a dependency more reliably, for example, without claiming it caused faster payment.

Evaluation must include the cost of getting the answer. A procedure that escalates every invoice may avoid some mistakes while consuming more staff time and creating more disputes. A useful comparison would consider decision quality, rework, human effort, retrieval and model cost, and adverse outcomes.

The candidate should also compete with a simple baseline: reliable records and an explicit checklist. A learning graph should earn its complexity.

Keep Lessons Scoped and Reversible

One client's exception should not become a company-wide rule by default. The additional acceptance check might apply only to materially changed milestones under a particular contract structure. Its scope belongs in the proposal.

An initial hypothesis could cover a few cases. Becoming a default for a broader class of work would require broader evidence and review. The source material's access restrictions still matter: rewriting a lesson in general language does not automatically make it safe to share outside a restricted client matter.

Time matters too. An approval may have been granted on Tuesday but recorded on Friday. The system needs both the effective time and the time it learned about the event to explain a Wednesday recommendation fairly.

Corrections should preserve which interpretation was used, subject to retention and deletion requirements. That lets a reviewer distinguish missing evidence from a mistaken interpretation or an unsuitable procedure. Each points to a different repair.

Accepted changes should have identifiable versions and a way back. If a new check creates needless escalation, the owner should be able to withdraw it without losing the history needed to understand what happened.

Learning Does Not Grant Permission

A useful shortcut does not authorise the assistant to remove a required approval. Observing that employees sometimes make exceptions does not turn those exceptions into policy.

In this design, mandatory controls sit outside editable guidance. When an action executes, it must still pass the current identity, permission and approval checks. The learning loop can propose a better way to work; it cannot grant itself more authority.

External material also needs care. OWASP's prompt-injection guidance describes risks from instructions embedded in documents and other content, alongside controls such as least privilege and human approval for high-risk actions.

For this proposal, the concern extends to learning: a malicious document must not become a durable instruction merely because a refiner calls it a lesson. Proposals need traceable origins, evaluation and review appropriate to their consequences. A plausible explanation from a model is not sufficient evidence for adoption.

That review should remain inspectable. Someone should be able to see the proposed change, its supporting cases, its limits and the reason it was accepted or rejected.

Start With One Recurring Decision

I would begin with the delivery-to-billing handover, limited to identifying unresolved acceptance conditions and preparing a recommendation for a person.

The initial model needs only a few concepts: projects, scope versions, milestones, acceptance evidence, approvers and invoices. Reliable identifiers and links across systems matter more than a particular graph database. Explicit relationships in ordinary tables would be a reasonable starting point.

Establish a baseline, then record what was known, what the assistant recommended, what the person decided and what followed. Human explanations are useful evidence about the decision; they are not automatically verified accounts of its cause.

Only then introduce small candidate changes. A reviewable proposal might say:

Separate acceptance of the original scope from acceptance of revised work. Add the check only when a material change is linked to the milestone. Test whether it catches missed acceptance without escalating unchanged work unnecessarily.

The product should show the effect of an accepted change. A person reviewing the recommendation should see the relevant scope revision, the missing evidence and the question to resolve. The owner should also be able to inspect why this check exists and which version introduced it.

That makes learning something people can challenge. Perhaps the scope change was immaterial. Perhaps another mechanism already establishes acceptance. Those corrections should reach the appropriate relationship or procedure instead of disappearing into a chat transcript.

The immediate task is to handle one overdue invoice well. The longer-term opportunity is to recognise the same ambiguity earlier: connect the next scope change to its acceptance requirement and ask the right person before the handover stalls.

A Twin that learns from experience should be able to show what changed, where the lesson applies and what would cause it to revise that lesson. The next decision should be better informed because the system has learned which context matters.