Predictika · Vendor Onboarding Check

Before an AI agent activates a new vendor, the onboarding file is checked

Tallgrass Foods, a fictional food company, lets an AI agent onboard vendors. Before the agent activates a vendor in the payables master, the call goes to Predictika’s Vendor Onboarding Check. It checks the vendor type, the tax form, the sanctions screening, the insurance, the bank verification, the expected spend, access to personal data and the security review, any conflict of interest, and the approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Tallgrass Foods is fictional. The scenarios are illustrative. The rules and thresholds are illustrative company policy, not legal advice.

Scope: one new vendor proposed for activation, judged against documents, screening, insurance, data and approval rulesSee everything this validator covers

This validator decides one thing: whether one new vendor may be activated, given the onboarding facts. It is not a vendor management system and not a compliance review.

  • Actions — activate one vendor of four types: goods suppliers, on-site service providers, software and cloud vendors, or independent contractors.
  • Rules — missing tax form, sanctions hit or no screening, missing insurance, unverified bank details, personal data with no security review, spend above two thresholds, conflicts of interest, high-risk vendor types, and personal data sign-off.

Within these rules the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not screen the vendor, read the tax form or check the certificate; those results are taken as stated facts.

What the validator sees: onboarding facts, never the forms or the screening reportRead more

The validator takes facts as inputs: the vendor type, whether the tax form is received, the sanctions screening result, the insurance status, whether the bank details are verified, the expected annual spend, whether personal data is handled and a security review is done, any conflict of interest, and the approval on record. These come from the onboarding system at the moment of the call. The validator never sees the forms, the screening report or the certificate.

Two honest limits. The validator judges the facts it is given: if the screening result is wrong, the answer follows it. And a vendor that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the activation workflow makes the call.

The AI agentProposes activating a vendor, says why it is fine, then calls the validator before activating.
Predictika validatorReads the onboarding facts, applies the rules, then returns one verdict.

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

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where onboarding tools get it wrong

Click to expand

General statements about onboarding tools, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

What the validator caughtTypical toolPredictika
Reading vendor type, documents and screening togetherCannot do it
Onboarding tools collect each document. Blocking activation when the type, the insurance, the screening or the data access do not line up takes a rule across all of them.
Every rule is checked on every call and the verdict lists each finding.
Different approval levels for different risksOnly if someone is vigilant
A workflow records that someone approved. Checking that the approver is the lead for a threshold and the finance director for a conflict or personal data has to be added.
Every rule is checked on every call and the verdict lists each finding.
Reporting every finding at onceOnly with workarounds
Many tools stop at the first missing item. A complete list for one vendor, with the level of approval needed, takes a rule set built to return it.
Every rule is checked on every call and the verdict lists each finding.
Required insurance missingOnly with workarounds
Whether insurance is required depends on the vendor type. A rule has to read the type and the insurance status together.
Every rule is checked on every call and the verdict lists each finding.
Sanctions screening hitOnly if someone is vigilant
A screening tool returns a hit. Stopping an agent from activating anyway needs a rule that reads the result at the moment of activation.
Every rule is checked on every call and the verdict lists each finding.
Personal data with no security reviewOnly if someone is vigilant
Data access and the security review live in different systems. A rule that reads both is what stops activation without the review.
Every rule is checked on every call and the verdict lists each finding.
Spend above the lead thresholdOnly with workarounds
An approval threshold is a number the workflow has to apply the same way every time, on the exact value, not on a rounded figure.
Every rule is checked on every call and the verdict lists each finding.
Tax form not receivedOnly if someone is vigilant
Most tools stop at the first failing check. Returning every finding together takes a rule set designed to do that.
Every rule is checked on every call and the verdict lists each finding.
Spend above the director thresholdOnly if someone is vigilant
A disclosure form can be filed and forgotten. A rule that asks the right person to decide, before activation, is what makes the disclosure count.
Every rule is checked on every call and the verdict lists each finding.

What this validator catches: findings from its test cases

Click to expand

Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off first.

1The vendor tax form has not been received.
2The sanctions screening returned a hit on this vendor.
3The vendor has not been screened against sanctions lists.
4On-site service providers need current insurance, and the insurance status is absent.
5The vendor bank details have not been verified by a call to a known number.
6The vendor will handle personal data and no security review has been done.
7Software and cloud vendors are a high-risk vendor type. The procurement lead must approve.
8Expected annual spend of 100001 is above 100000. The finance director must approve.
9Conflict of interest disclosed
10High-risk vendor type
11The vendor will handle personal data. The finance director must sign off on the security review.

Scenarios and results

Click to expand

The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

1. Insurance: A service provider with no insurance

The agent's request. I'm activating this cleaning contractor. The tax form and screening are clear and the spend is small.

Verdict: Blocked.

  • Required insurance missing. On-site service providers need current insurance, and the insurance status is absent.

2. Insurance: Insurance now on file

The agent's request. I'm activating this cleaning contractor. The tax form and screening are clear, the spend is small, and a current insurance certificate is now on file.

Verdict: Allowed.

3. Screening: A sanctions screening hit

The agent's request. I'm activating this supplier. The tax form is in, the bank details are verified, and the screening hit is probably a name coincidence.

Verdict: Blocked.

  • Sanctions screening hit. The sanctions screening returned a hit on this vendor.

4. Data: Personal data, no security review

The agent's request. I'm activating this supplier. It will see some employee details for deliveries, but spend is only 10000.

Verdict: Blocked.

  • Personal data with no security review. The vendor will handle personal data and no security review has been done.

5. Spend: Expected spend of 25001

The agent's request. I'm activating this supplier. Every document is in order and the expected spend is 25001.

Verdict: Needs approval.

  • Spend above the lead threshold. Expected annual spend of 25001 is above 25000. The procurement lead must approve.

6. Spend: Procurement lead approval on record

The agent's request. I'm activating this supplier at 25001 expected spend. The procurement lead has approved it.

Verdict: Allowed.

  • Spend above the lead threshold. Expected annual spend of 25001 is above 25000. The procurement lead must approve.

7. Several problems: A contractor with four blocking findings

The agent's request. I'm activating this contractor. The business needs them to start, and the paperwork will follow. The expected spend is 150000.

Verdict: Blocked.

  • Tax form not received. The vendor tax form has not been received.
  • Sanctions screening hit. The sanctions screening returned a hit on this vendor.
  • Required insurance missing. Independent contractors need current insurance, and the insurance status is absent.
  • Bank details not verified. The vendor bank details have not been verified by a call to a known number.
  • Spend above the director threshold. Expected annual spend of 150000 is above 100000. The finance director must approve.
  • Spend above the lead threshold. Independent contractors are a high-risk vendor type. The procurement lead must approve.

8. Conflicts: A disclosed conflict of interest

The agent's request. I'm activating this supplier. A buyer disclosed a connection to the owner, but the spend is only 10000.

Verdict: Needs approval.

  • Spend above the director threshold. A conflict of interest was disclosed for this vendor. The finance director must approve.

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. Tallgrass Foods, a fictional food company, lets an AI agent onboard vendors. Before the agent activates a vendor in the payables master, the call goes to Predictika’s Vendor Onboarding Check. It checks the vendor type, the tax form, the sanctions screening, the insurance, the bank verification, the expected spend, access to personal data and the security review, any conflict of interest, and the approval on record. Then it returns one verdict: allow, needs approval, or block.
  2. I will start with the first request by the agent.
  3. The agent says. I'm activating this cleaning contractor. The tax form and screening are clear and the spend is small.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with one finding, all in one answer. On-site service providers need current insurance, and the insurance status is absent.
  6. The validator returned one blocking finding in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
  7. What this shows: for required insurance missing, a tool can do this only with workarounds.
  8. Now the agent resubmits.
  9. The corrected request. It changes the insurance to current.
  10. It calls the validator again.
  11. This time the validator clears it.
  12. The earlier finding is cleared.
  13. One problem caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs.