Predictika · Spend Action Validator

Before an AI agent moves money, the action is checked

Ridgeline Fabrication lets AI agents work its procure-to-pay queue: creating suppliers, changing bank details, raising POs, approving invoices, releasing payments. Before any of them acts, the call goes to Predictika's Spend Action Validator. It checks the action against the supplier's record, the bank account's history, the contract, the approval chain, and the person each agent is acting for. Then it returns one verdict: allow, needs approval, or block.

Scope: six procure-to-pay agent actions (create supplier, change bank details, raise a PO, approve an invoice, release a payment, change an approval limit)See everything this validator covers

This model covers six specific actions an agent can take in a procure-to-pay suite, not "AI agents" in general:

  • Supplier master — create_supplier and update_bank, gated by where the instruction came from, who owns the account, whether it is already used, and whether it moves abroad.
  • Purchasing — create_po, gated by the contract's not-to-exceed, its expiry date, and the running 30-day total with the supplier.
  • Invoice and payment — approve_invoice and release_payment, gated by separation of duties across the PO, receipt, approval and payment, the age of the supplier record, and the hold period after a bank change.
  • Authority — change_authority, gated by who is changing whose approval limit.

Within these six actions the validator handles any combination the catalog can produce, not just the seven scenarios on this page, which are a sample chosen to show each kind of check. It does not cover invoice content checks (duplicate or inflated invoices), expense reports, sourcing events or supplier onboarding questionnaires unless those are added.

Why context matters: an agent that inherits its user's permissions can do whatever that user can, at machine speedRead more

An agent that inherits its user's permissions can do whatever that user can do, at machine speed. The frauds that cost real money in procure-to-pay are rarely one bad step. They are several ordinary steps, or one ordinary step at the wrong moment. Three kinds of context decide these cases, and none of them is visible from the action alone:

  • Timing. When did the supplier's bank account last change, and did anyone confirm it by phone? An invoice that passes every check can still be unsafe to pay today.
  • Provenance. Where did the instruction come from? A bank change found in an email or an attachment is a request from an unknown sender, not authority from the supplier.
  • Who the agent is acting for. Agents have their own identities, but separation of duties only works if the checks resolve back to the human on each step: who created the supplier, who raised the PO, who received the goods, who is paying.

Every rule fires independently and every fired rule is reported, so nothing here is a single pass/fail gate. The ghost-vendor scenario trips four rules at once and shows all four.

Two honest limits

The validator judges what it is shown. The facts on each tab (supplier record, bank-change history, contract totals, who did what on an invoice) are read from the suite's records at the moment of the call. This page uses a small fictional catalog. How those records reach the validator in a real deployment is an integration question, not something this page settles.

An agent that never calls the validator is not checked. In this demo the agent calls the validator itself before acting. Making the call mandatory means the suite, or the gateway agents reach it through, makes the call on the agent's behalf.

The AI agentProposes an action in the P2P suite, says why it is fine, then calls the validator before running it.
Predictika validatorReads the supplier, account, contract and invoice records, resolves who each agent acts for, then returns one verdict.

7 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

Looked up server-side before evaluation

    The agent says

    Before acting, the agent must call Recorded run

    Predictika validator

    
      
    
        
        
        
      
    
      
    Waiting for the call.
    
      
    
    
  
    

  


  
    
    
    Where an AI agent gets this wrong on its own
    Click to expand    
    
    Our assessment of what an AI agent working alone does with the same cases, without a check on the records behind the action. It is a judgment about reliability from public descriptions of how agents and procure-to-pay controls work, not a claim about any particular product.
    
    
    What the validator caughtAn AI agent on its ownPredictika
    Bank details from an email or attachment, and an account moved to another countryError-prone
    An agent that inherits its user's permissions has the right to update the supplier record and no built-in reason to doubt a PDF: it reads a document and acts on it. An instruction found inside an email or attachment is a request from an unknown sender, not authority from the supplier.    		Where the instruction came from is an input. Text in an attachment cannot authorize a bank change, and an account in another country needs a treasury review whatever the source.
    Payment right after a bank changeError-prone
    Every box the invoice carries is ticked: approved, matched, account ownership checked. Whether the account changed four days ago, and whether anyone confirmed it by phone, is a relationship between two dates that the invoice does not show.    		The payment date and the bank-change date are both inputs, and the hold period is checked on every call.
    Paying an invoice that its own principal receivedError-prone
    A payment under the agent's approval limit, on an approved invoice, to a long-standing supplier. Nothing in the action itself is out of range; the finding is about the person the agent acts for.    		The check resolves each agent back to the person it acts for and compares that person with who raised the PO, received the goods and approved the invoice.
    A ghost vendor built in several ordinary stepsError-prone
    Each step is within a limit on its own: a supplier created by someone allowed to create suppliers, a PO under the agent's limit, a payment by someone allowed to pay. The same person appears at every step, and the agent does not hold that picture.    		All four findings come back together, so a reviewer sees the whole picture and one fix cannot hide another.
    
  
    

  
    
    
    How sure are we that each scenario is a gap?
    Click to expand    
    
    This rests on public material only. Anyone with a real deployment in front of them will know better than we do, and we would rather be corrected than sound certain.
    
    
    
  
    

  
    
    
    What this validator catches
    Click to expand    
    
    Every finding the validator returned across all 32 test runs, with the wording it used. Each finding is reported and none stops the others, so one violation can never hide another. A block means the agent must not do this; a review means a person must sign off first.