The New Interface Between Expertise and Software

The smallest useful decision record

A practical record can be compact. For one recurring decision, capture seven fields:↗

• Input: the facts and assumptions presented with the request.
• Controlling source: the current policy, agreement, or approved record that governs it.
• Rule: what happens when the request fits the source’s stated conditions.
• Exception: the condition that invalidates the routine path.
• Permitted action: what the system or operator may do within existing authority.
• Escalation: who resolves what remains outside that authority, including specialist input where relevant.
• Update owner: who changes the record when a decision establishes or revises the rule.

These fields do not require one universal data model. They are a test of whether the organization has made enough judgment visible for software to participate without inventing policy.

Illustrative example: a pricing exception

Consider a request to prepare a customer proposal. The same request can move through an ordinary path, become an exception, receive a decision, and then improve the governing record.↗

On the ordinary path, the proposed scope and terms fit the approved policy. Software can locate the controlling source, assemble the proposal, expose its assumptions, and prepare the work allowed by existing authority.

Now keep the request but change one fact: the scope is nonstandard or the applicable terms conflict with the routine policy. The exception is no longer a vague sense that “this one is different.” It is a named condition that invalidates the ordinary path. The system can still prepare the proposal and rationale, but it cannot infer authority to commit.

The unresolved exception goes to the named commercial owner. Finance or legal can contribute where the issue falls within their responsibility. The resulting decision is attached to the request so a reviewer can reconstruct what governed the outcome. If the decision changes how future requests should be handled, the named policy owner updates the record. If it does not, the exception remains a decision about this request rather than silently becoming a new general rule.

No discount threshold or commercial outcome needs to be invented for the example to work. What matters is the path: ordinary handling, detected exception, authorized decision, and an explicit choice about whether the rule changes.

This is where evidence belongs. A material assertion or action should point to the source that controls it, with a locator another reviewer can follow. The evidence does not become stronger because it is entered in a table. A first-party policy remains a first-party policy; it proves the organization’s current position, not an independent market fact. Traceability lets a reviewer see that distinction instead of receiving a polished answer with its basis hidden.↗

The record also makes software easier to change and operate. When policy, terms, or delegated authority change, the update owner knows what to revise. The system does not have to treat a past conversation as timeless expertise. It uses the current record, preserves the exception and decision, and exposes uncertainty rather than smoothing it away. Operators can then verify whether the resulting proposal, escalation, and commitment followed the maintained decision rather than guessing from the final output.

This creates a different implementation backlog. Which recurring decisions have a controlling source? Which routine rules contain exceptions that experienced operators recognize but software cannot? Which actions may be prepared, and which may be committed? Who resolves the exception? Who updates the rule afterward?

These are not documentation questions added after the software is built. They define the interface people and agents need in order to build, run, and improve useful systems within real authority.

This is the kind of problem Praxso works on today: entering a complex software or operating environment, capturing the domain rules and exceptions, structuring them into an executable source of truth, and building the system that carries the work. The current offer is a concrete outcome delivered through services. The longer-term direction is reusable software, infrastructure, and intellectual property drawn from patterns that recur across hard engagements—not a claim that a finished SaaS product or proven moat already exists.↗

Start with one recurring decision. Complete the seven-field record: input, controlling source, rule, exception, permitted action, escalation, and update owner. Then run one ordinary request and one exception through it. The gaps you find are the next interface to build.

Method note: This essay was drafted and revised with AI from PRAXSO’s governed source material and owner-provided editorial direction. The pricing exception is illustrative, not a client case or reported result. AI participation does not confer authority to publish or to make a commercial commitment; those remain with the responsible people.