VANKPA
Set clear limits for the information automation uses, the work it prepares, and the actions people approve.
Before a tool drafts, recommends, routes, or acts, agree on its role. Define which information it can use, who checks important outputs, and which actions need approval. These decisions make automation easier to test and manage.
Define authority before choosing tools
Teams often begin with what a model can generate, summarize, classify, or trigger. A more durable starting point is what the operating process is allowed to decide, which role owns that decision, and what consequence follows if the system is wrong.
This reframes automation as a governed part of the business rather than a detached technical feature. The model, workflow, and interface can then be selected around an explicit authority boundary instead of inheriting one accidentally.
The system should never appear more authorized than the organization has decided it is.
Keep the evidence
A useful recommendation should preserve the records, definitions, dates, assumptions, and limitations that shaped it. Reviewers need a visible route back to the source instead of a polished answer that has lost its provenance.
When source quality is uncertain, the interface should communicate that uncertainty directly. Confidence language, missing evidence, conflicting records, and recency all belong near the prepared output rather than in a separate governance document.
- Name approved sources
- Show recency and missing evidence
- Preserve links to supporting records
- Keep assumptions distinguishable from observations
Separate work from approval
Drafting a response, recommending an action, changing a record, and communicating with a customer carry different levels of consequence. They should not share one undifferentiated permission just because the same system can technically perform them.
A clear workflow names which steps are automatic, which create a reviewable proposal, which require explicit approval, and which remain fully human. That separation makes the operating model easier to test, explain, and improve.
Design the stop and review path
Every accountable automation needs a visible way to pause, reject, correct, and escalate. The exception path is not secondary behavior; it is where the organization proves that human judgment still governs consequential outcomes.
Review should also create learning. A rejected recommendation, corrected source, or changed decision can be recorded without silently teaching the system from unverified feedback. The result is a controlled improvement loop rather than an expanding black box.
- Provide a clear pause state
- Record who approved or rejected the action
- Preserve the reason for an override
- Review patterns before expanding authority
