Scenario
A financial operations team receives a request to approve a wire transfer exception. The tools are available. The request looks urgent. Supporting materials appear to be present. A scalar or speed-first workflow may be tempted to ask only whether the transfer can be processed and whether local friction can be minimized.
The PV-PP question is different: is the action viable under current evidence, authority, recovery conditions, and domain state? The framework does not stop at visible availability. It asks whether execution remains structurally sound.
What is available versus what is viable
Available
The system may expose the wire tool, exception workflow, customer record, transaction screen, and approval path. These are real capabilities, but they do not by themselves settle whether the action should proceed.
Viable
Viability asks whether the proposed action survives the governing checks that matter for this case: authority, evidence sufficiency, fraud risk, recovery options, compliance obligations, and the current decision state.
That difference is the heart of the example. The tool registry answers what is available. The PV-PP framework asks whether the action is viable enough to enter execution or approval.
Governing constraints
In this scenario, several conditions are governing rather than compensatory. That means they are not just “costs” that can be outweighed by speed, convenience, or apparent business gain.
- Authority: Does the requesting party actually have permission to authorize this exception?
- Evidence sufficiency: Are the supporting records current, complete, and adequate for this decision?
- Fraud / compliance exposure: Does the request create a risk profile that requires escalation or block?
- Recovery: If the action is wrong, is there a realistic path to containment or reversal?
- State validity: Is the system currently in a condition where the transfer can be responsibly evaluated at all?
These conditions are the reason the framework is non-scalar here. Missing authority or broken recovery is not merely an inconvenience. It changes the admissibility of the action itself.
Why a simple scalar ranking fails
A scalar approach may rank the action highly because the request appears urgent, the client relationship looks important, and the operational path is available. On a one-score logic, those gains can swamp softer warning signals.
But in this case the warning signals are not merely softer. They are governing. If authority is unclear, evidence is stale, or recovery is implausible, a fast approval can look locally efficient while remaining globally fragile. Visible completion then becomes false success rather than real viability.
How the PV-PP framework handles the case
That sequence is what makes the framework operational rather than rhetorical. It forces structural checks before apparent convenience is allowed to decide the case.
Outcome
In the worked example, the right PV-PP result is not “approve because the tool exists” or “approve because the case is urgent.” The result depends on whether the action survives the governing filters. If authority is missing, evidence is insufficient, or recovery is not credible, the action should be blocked or escalated rather than optimized.
This is the point of the framework in practice: not every available action is viable, and not every visible completion counts as success.
What this example shows
- Value and capability are not the same thing.
- Availability and viability are not the same thing.
- Some conditions govern action rather than merely influencing it.
- Pre-execution evaluation matters because downstream recovery may be weak or nonexistent.
- Non-scalar structure becomes necessary when authority, evidence, safety, and recovery cannot be traded away.