PALO FRAMEWORKAn AI governance evidence bundle connects a decision to its context, accountable owner, controls, observations and unresolved questions. It helps another reviewer understand what was assessed and what still needs to be established. A valid file format is only one part of that evidence.
This walkthrough uses PALO's existing fictional invoice-exception case. It is an educational example with synthetic data and no payment, supplier or production connection. The reported sample outcome is not a measurement of a deployed system.
Start with the decision and authority boundary#
The question is whether an agent may collect invoice-exception evidence and draft a proposed resolution while a named person retains release authority.
The sample permits reading synthetic invoice metadata and drafting an exception summary. It prohibits releasing a payment, changing supplier data or contacting the supplier. These distinctions belong in the record before the agent acts; an instruction to "handle the invoice" would leave the boundary unclear.
Open the worked case in PALO Assessment Path or inspect the source Case File.
Follow the six governance phases#
| Phase | Question for the reviewer | Evidence to preserve |
|---|---|---|
| Frame | What use is intended, who is affected and who owns the decision? | Purpose, system boundary, owner and explicitly prohibited actions |
| Classify | Which risk route is plausible, and what context still needs review? | Screening assumptions, source references and unresolved classification questions |
| Assess | What could go wrong for people or delegated actions? | Impact questions, authority boundaries and oversight requirements |
| Control | What prevents or detects actions outside that boundary? | Proposed tool restrictions, reviewer identity and verification requirements |
| Measure | What observation would show that the intended effect occurred? | An expected draft and an independently checked, unchanged payment state |
| Prove and review | What can the evidence support, and what remains open? | Dated records, provenance, limitations, reviewer decision and follow-up |
The framework's phases organize the review. They do not make the sample's proposed controls production controls.
Separate permission from the observed result#
A policy decision allowing draft_exception says what may be attempted. It does not prove that the agent produced the right draft or avoided every prohibited effect.
The sample's expected post-state is:
{
"draftCreated": true,
"paymentReleased": false
}A reviewer should also consider the other prohibited effects: supplier data must remain unchanged and no external supplier message should be sent. In a real implementation, the verification method, observation source and its trust boundary need separate validation. A tool's own success message is not independent evidence of all external effects.
Read the example decision carefully#
The source case records proceed-with-conditions. Its conditions are to keep payment release outside the agent's tool set, require reviewer identity and verify the post-state independently.
That record is an illustrative decision, not an approval of your use case. Reviewers must establish whether those controls exist, are effective in the intended environment and cover the actual risks. Missing evidence should remain visible rather than becoming an implicit pass.
Export and hand over a useful record#
Use the Assessment Path to connect the context, screening and impact questions to controls and indicators. Export the local evidence bundle and review its version, source references, assumptions and unresolved questions before sharing it.
Keep the original Case File and subsequent observations distinguishable. A schema-validation receipt proves that the file conforms to a contract; it does not establish legal compliance, security effectiveness or production authorization.
The Case File and Evidence Bundle guide describes the interoperable record. Use the board review template to structure an accountable handover and the indicator examples to plan follow-up measurement.
Sources and related methodology#
The worked facts above come from the versioned PALO sample. The sample references the NIST AI Risk Management Framework as a starting point. Its inclusion is not an endorsement or a certification of PALO.
For the wider operating model, read the PALO lifecycle guide, semantic foundation and agentic governance modality.