What Does an AI Assurance Badge Cover?

Put these two claims beside each other.

“Our AI is certified.”

“Illustrative Provider 0001's Client Research Synthesis Service meets the named demonstration criteria for the listed uses, teams, tools, data classes, jurisdictions, evidence period, exclusions, and current status at this record.”

The first is broad enough to sell.

The second is narrow enough to inspect.

That difference is the entire product.

An AI assurance badge should cover a bounded AI-enabled service environment. It should not imply that every model, employee, workflow, output, office, or client engagement at the provider has been certified.

The buyer needs an object, not an adjective

“Responsible.” “Safe.” “Compliant.” “Trusted.”

These words sound comforting and collapse under a procurement question.

What, exactly, was reviewed?

A useful assurance record names:

1. The legal entity. The organization responsible for the claim.
2. The service boundary. The service lines, teams, workflow stages, and locations included.
3. The registered AI uses. The purposes for which AI is used inside that boundary.
4. The tool and supplier classes. The covered model, platform, and third-party categories.
5. The data classes. What information may enter the covered uses and under which restrictions.
6. The jurisdictions and sector rules. The legal and professional context for the claim.
7. The evidence period. The operating window the assessment examined.
8. The exclusions. The uses, teams, clients, tools, or data outside the claim.
9. The assessment and decision roles. Who gathered evidence and who made the independent decision.
10. The current status. Certified, conditional, under review, suspended, withdrawn, expired, or superseded.
11. The change history. What changed, when, and how the public claim responded.
12. The complaint and evidence paths. How a buyer asks for more information or reports a concern.

If the record cannot answer those questions, the buyer is still doing reconstruction work.

The model is not the service

A model can be tested for defined properties under defined conditions. That evidence may matter. It does not tell the buyer how a provider uses the model inside client work.

The service boundary contains more:

→ people who decide when AI may be used

→ workflow steps where AI enters or stops

→ client instructions and contractual restrictions

→ data classification and access rules

→ evaluation methods tied to the task

→ evidence, exceptions, incidents, and approvals

→ supplier changes and monitoring

NIST's AI Risk Management Framework is voluntary and speaks across AI products, services, and systems. It does not certify firms. Its breadth reinforces the object problem: “AI” can refer to many different things, and the claim has to name which one is under review.

The proposed AI Service Assurance object is the provider's bounded client-service environment.

Exclusions are part of the positive claim

Marketing teams like the included list. Buyers learn from the excluded list.

A record may include AI-assisted research synthesis using approved enterprise tools and exclude:

• autonomous client communication;
• final legal, medical, financial, or safety judgments;
• unapproved consumer accounts;
• biometric inference;
• training on client content;
• named jurisdictions;
• subcontractor workflows not yet assessed; or
• new tools pending material-change review.

The exclusions cannot hide in page twelve of a PDF.

The FTC's guidance on seals warns that broad symbols can communicate claims beyond their supported basis. Clear limits belong near the positive signal. A link can add detail. It cannot repair a misleading headline by itself.

Current status changes the answer

The same boundary can produce different buyer decisions across time.

Certified last quarter does not mean current after a new model supplier, new client-data use, material incident, or expired evidence period. The registry must show the status now, the date of the last decision, the next review point, and any material-change flag.

See why the badge must be able to turn off.

The demonstration record makes scope inspectable

The attached concept registry record uses an obviously fictional provider, a non-issued demonstration ID, and a persistent warning banner.

It shows the proposed buyer experience:

• one concise scope sentence;
• included and excluded uses;
• standard and evidence dates;
• separate assessment and decision roles;
• a material-change flag;
• named capability examples;
• status history; and
• buyer evidence and complaint paths.

It is not a certificate. It is a design object for comprehension and legal-boundary testing.

Petrichor's current AI Assurance work is readiness and implementation, not certification. The certification, registry, and mark described here are a proposed market architecture that still requires independent governance, validation, and legal review.

Certification would not guarantee the outcome

Even a valid certificate would not guarantee:

• perfect accuracy;
• legal compliance in every jurisdiction;
• absence of bias or harm;
• acceptance by a specific client;
• approval of an unregistered use;
• safety of every model output;
• freedom from incidents;
• coverage beyond the named boundary; or
• continued status after a material change.

The provider keeps responsibility for the service. The buyer keeps responsibility for its decision. A certification body would remain responsible for the quality and independence of its own assessment and decision work.

The USPTO's certification-mark guidance separates the mark owner from authorized users and requires control over use. That is one reason Petrichor cannot blur current implementation work with a future independent certification claim.

Petrichor can build the evidence now

Petrichor's current claim-to-evidence control can help a firm build:

• a bounded service and workflow map;
• a register of material AI uses;
• approved tools, data classes, and restrictions;
• current claim and control evidence;
• named owners and review dates;
• documented exceptions and decisions; and
• a client-facing permission pack.

That material can support a buyer conversation now. It does not certify the provider or guarantee the buyer's answer.

The 60-second buyer check

Before relying on any AI assurance badge, ask:

1. Who is making the claim?
2. What exact service is covered?
3. Which uses, tools, people, data, and places are included?
4. What is excluded?
5. Which requirements and version apply?
6. Who assessed and who decided?
7. What operating period does the evidence cover?
8. What is the status today?
9. What changed since the last decision?
10. What does the certificate refuse to promise?

No clear answers? No usable permission object.

Buyer utility still has to be measured

The architecture has a final burden. It has to create economic utility, not just a more elegant record.

See how AI Permission Cycle Time will test that question.

Frequently asked

What does AI assurance certify?

In the proposed architecture, it certifies that one bounded AI-enabled client-service environment meets stated requirements for a defined period and current status. It does not certify “AI” in the abstract.

Can an AI model be certified?

A model can be tested or assessed against defined requirements. That is narrower than certifying the service system in which people use it for client work.

Is AI governance the same as AI assurance?

No. Governance sets authority, rules, and oversight. Assurance examines evidence and supports a conclusion about a stated claim. A functioning service system needs both.

Does a badge guarantee compliance or accuracy?

No. A credible record states its requirements, boundary, evidence period, and limitations. Client-specific legal and risk decisions remain with the responsible parties.

How should a buyer verify a claim?

Open the canonical registry record. Check status, scope, dates, exclusions, standard version, assessment and decision roles, change history, and the certificate ID. Do not rely on the image alone.