Thoughtware in Practice

The architectural ideas in this paper become clearer when applied to an ordinary operational problem. Consider invoice exception resolution, a process found in many organisations whenever an invoice does not match the purchase order or expected delivery against which it was raised. The problem is useful because part of it is perfectly deterministic while another part requires interpretation and judgment. It therefore illustrates why Thoughtware is not simply the replacement of conventional software with models, but the deliberate allocation of different kinds of responsibility.

A traditional invoice-processing system can handle a large portion of the workflow through rules. It can retrieve the invoice and purchase order, compare totals, calculate numerical variance, check whether the vendor is active, apply configured tolerance thresholds, and route the case to an approver according to organisational policy. If an invoice is within a permitted percentage or absolute variance, it may pass automatically. If it exceeds the threshold, the system may create an exception.

For sufficiently predictable cases, this works well. The difficulty begins when the meaning of the exception cannot be inferred from the numbers alone.

Suppose the ordered and invoiced quantities differ only for some line items. The vendor has included an explanation in an email. Part of the shipment was damaged and replaced separately. A contract permits particular substitutions or quantity adjustments under defined circumstances. Similar discrepancies from the same vendor have previously been accepted because of a known fulfilment arrangement. The invoice may still fail a numerical comparison even though the discrepancy is legitimate.

Traditional rules can be expanded to cover some of these conditions, but complexity grows quickly. Each new form of exception requires another branch, field, status, or manual intervention. The difficulty is not merely that there are many rules. It is that the system must determine what the available evidence means in the particular situation before the relevant rule can even be applied.

A Thoughtware architecture separates these responsibilities.

At the centre of the system might be an Agent with the goal Resolve Invoice Exception. The Agent does not itself need to own every judgment involved in the process. Its responsibility is to move the exception toward a valid resolution by coordinating deterministic operations and specialised Cognitive Units.

The process may begin conventionally. Deterministic software retrieves the invoice, purchase order, goods-receipt information, vendor record, and related documents. It calculates the exact numerical variance and validates that the case is eligible for processing. None of these operations requires cognitive interpretation, so introducing model-driven behaviour would add little value.

Cognitive responsibility begins where meaning must be established. An Interpret Discrepancy CU can determine what actually differs between the invoice, purchase order, delivery records, and accompanying explanation. A Determine Likely Cause CU can distinguish among possibilities such as pricing error, partial fulfilment, damaged goods, authorised substitution, duplicate billing, or an unexplained variance. An Assess Supporting Evidence CU can judge whether the available documents adequately support the explanation.

Further judgments can remain separate. A Judge Materiality CU can assess whether the discrepancy is significant in light of value, policy, contractual conditions, and risk. A Recommend Resolution CU can propose an appropriate response, such as accepting the invoice, requesting a corrected invoice, adjusting the payable amount, seeking additional evidence, or disputing the charge. A final Judge Escalation capability can determine whether the proposed resolution falls within the system’s permitted authority.

These responsibilities are separated because they have independent meaning. Assessing evidence is useful beyond invoice processing. Materiality may be a recurring financial judgment across several workflows. A capability for judging whether available evidence adequately supports a claim may eventually be shared across procurement, expenses, insurance, compliance, or customer disputes. The architecture therefore creates the possibility of reusable cognition rather than embedding the same reasoning repeatedly inside each workflow.

Some of these operations, however, always occur together. Retrieving the invoice and purchase order, interpreting the discrepancy, calculating the variance and judging materiality form a recognisable capability: verifying an invoice against the order it was raised against. The answers vary from case to case, but the shape of the work does not. That capability can be named and packaged as a Skill.

A second Skill sits at the other end of the process. Applying an approved adjustment involves verifying permissions, writing the adjustment, updating the accounting system, notifying the relevant parties and creating an audit record. This composition contains no cognition at all, which is a useful demonstration in itself: a Skill is defined by having a known procedure, not by being predominantly cognitive.

With these capabilities available, the Agent’s own reasoning becomes considerably smaller. It inspects the case, invokes Verify Invoice, examines the result, decides whether further evidence is required and invokes Collect Missing Evidence if it is, consults a Recommend Resolution Cognitive Unit, and then determines whether to act within its authority or escalate. It chooses between meaningful capabilities rather than micromanaging every underlying operation, and each capability can be evaluated at the level it actually promises.

Knowledge and experience also play distinct roles. The relevant contract and procurement policy provide knowledge against which the current case can be interpreted. Vendor history and previously resolved exceptions provide experience. If repeated cases reveal that a particular discrepancy pattern is routinely legitimate under a specific contractual arrangement, that pattern may eventually become explicit expertise, allowing familiar exceptions to follow a shorter and more reliable path.

The Agent orchestrates these capabilities according to the situation. A simple exception may require only interpretation and a materiality judgment before being resolved. An unusual case may require additional evidence, consultation of contractual knowledge, comparison with previous cases, and several rounds of review. The trajectory is therefore adaptive without requiring every underlying judgment to become part of one opaque reasoning loop.

Authority remains separate from capability. The system may be perfectly capable of recommending a large adjustment without being authorised to execute it. An organisation might allow low-value, reversible, well-supported exceptions to be resolved automatically while requiring approval when the financial value exceeds a threshold, evidence is contradictory, the vendor is high risk, or the case falls outside familiar patterns. Human involvement is therefore not an exception to the architecture. It is one deliberately designed destination within it.

Once a resolution is approved, execution returns to deterministic software.

Permissions are checked. Adjustments are written to the accounting system. Transactional integrity is preserved. Notifications are issued. Audit records are created. The cognitive system decides what should happen within its authority, while conventional software ensures that the action happens exactly and traceably.

Evaluation surrounds the cognitive portion of the system. The Interpret Discrepancy CU can be tested against representative and difficult exception cases.

The evidence-assessment capability can be evaluated for whether it distinguishes genuine support from irrelevant documentation. Materiality judgments can be compared with decisions made by experienced finance professionals. Resolution recommendations can be scored for policy compliance, proportionality, financial correctness, and consistency across comparable cases. Escalation can be evaluated for both unsafe under-escalation and costly over-escalation.

The Agent itself requires another level of evaluation. Did it call the appropriate capabilities? Did it retrieve unnecessary information? Did it repeatedly reconsider a conclusion that was already sufficiently supported? Did it exceed its authority? Did it ask for additional evidence when appropriate? Did it escalate cases that could reasonably have been resolved automatically? Did it reach the correct outcome through an efficient and defensible trajectory?

Over time, the system can improve without simply accumulating longer prompts. Evaluation may reveal weak Cognitive Units that need better knowledge, different implementation strategies, or revised decision boundaries. Frequently repeated judgments can be consolidated into reusable capabilities. Familiar trajectories can become fast paths. New experience can refine expertise. At the same time, unusual cases can continue to fall back to slower deliberation or human judgment.

Invoice exception resolution therefore illustrates the larger structure of Thoughtware. Deterministic code handles what can be specified precisely. Cognitive Units own bounded judgments. An Agent coordinates those capabilities toward a goal. Knowledge and experience inform decisions without becoming undifferentiated memory. Evaluation determines whether behaviour is actually improving. Authority defines where machine responsibility ends and human responsibility begins.

The result is not an “AI feature” attached to an invoice system. It is a software architecture in which computation and cognition are deliberately assigned to the forms of work each is best suited to perform.