You should not put a Role Assistant in front of users until two things are true: the Connected Systems behind it are certified for the intended scope, and the Role Assistant is proved to understand and complete the role’s work correctly for an identified person — including when it must ask, wait, deny, or stop safely.
Generation creates a candidate, not authority. A technically successful execution is not proof of a correct business outcome. Teams validate the generated business definition and prove representative business cases before an administrator makes an approved version available.
Why it matters
Typical AI programs stall between a convincing demo and production because nobody can answer two questions with evidence (Why Enterprise AI fails):
-
Are the systems safe and correct? Can this person see and use only what they may, and do certified capabilities behave correctly against the authoritative systems?
-
Is the business capability correct for this role? Does the generated Role Assistant understand the approved business meaning, relationships, measures, rules and expected outcomes — and still complete this role’s work correctly for this person?
These are different failures.
An integration can be technically correct while the generated business meaning is incomplete or wrong. A field may be available but poorly described, a measure may lack its unit or time basis, a relationship may be missing, or the available data may be insufficient to support the requested conclusion.
Without both proofs, production is a bet. Legal, security, business owners and operations cannot reliably sign off.
Different tools prove different parts of this problem:
| Approach | Primary proof | What remains separate |
|---|---|---|
| Integration testing | APIs, mappings, authentication and technical execution | Business meaning and role-specific outcomes |
| Agent / model evaluation | Agent responses, tool use and model behaviour | Certification of the underlying enterprise capability |
| Workflow testing | Behaviour of the encoded process | Whether the underlying business definition and available context remain correct |
| AI Fabrix | Certified systems + approved business capability for an identified role and scope | Operational Trust still applies at runtime |
These approaches are complementary. Integration tests prove technical contracts, agent evaluations assess AI behaviour, and workflow tests prove encoded processes. Workflow and business-process engines are testable. The expensive failure is using them as a substitute for certified systems and proved Role Assistant outcomes: each project still encodes a process graph, then still cannot sign off that the systems are safe or that the assistant gave a correct governed answer.
Agent SDKs and tool loops have the same gap. Teams rebuild prompts, tools, and evals per use case. There is no shared certification of the systems of record, and no proof that this role’s assistant still completes the work for an identified person.
That is why AI programs stall after a convincing demo — not because a stored process graph cannot be unit-tested. The cost is rebuilt pilots and production without evidence.
AI Fabrix adds a business-level proof boundary: the systems must first be certified, and the generated Role Assistant must then be proved against approved business expectations for an identified role and scope.
The proof therefore remains attached to the business expectation, rather than only to a particular model, prompt, workflow implementation, or integration.
How it works
What this shows: AI Fabrix proves business readiness in sequence. First, the required systems must be trustworthy for the intended scope. Then the generated business definition must reflect the approved business meaning. Finally, representative cases prove that the Role Assistant gives the expected outcome for an identified person — including when it must ask, wait, deny, or stop safely.
What this is not: an agent SDK eval harness, a workflow engine, or a substitute for Operational Trust at runtime.
There are still two independent production proofs:
| Proof | What it answers | Without it |
|---|---|---|
| Connected System certification | Can the required enterprise capabilities execute safely and correctly for the intended scope? | A correct-looking AI answer may rely on an uncertified system capability |
| Role Assistant proof | Does the generated business capability correctly represent the business and produce the expected outcomes for identified people? | You cannot prove business correctness for the role |
The Role Assistant proof contains two steps: validate the generated business definition, then prove representative business cases.
A green system certification does not prove the Role Assistant. A green assistant smoke check does not prove the systems.
Operational Trust still verifies the person, role and scope on every request. Certification proves readiness for a defined scope; it is not permanent authorisation.
Integrators run Connected System certification on the Build track. They prove Role Assistants with lifecycle checks and representative cases. Case authoring and promote stay under Operate.
Configure next: Role Assistant tests.
What Role Assistant proof validates
Governed Result
A completed run has one governed Result: the business-readable outcome of that work (including wait, deny, fail, or safe stop). Operators read labels and state. Technical identifiers stay in a restricted trace — they are not a second system of record.
The platform does not invent primary keys. A search that returns no rows is not proof that nothing exists when completeness is unknown.
Richer named-record, service, and document Result screens, and a shared Task Execution details shell, may still be rolling out. The honesty of the Result does not wait on those screens.
Validate the business definition
Before behavioural cases are run, validate that the generated capability accurately represents the approved business specification.
Depending on the capability, this includes:
- business entities and their meaning;
- fields and business terminology;
- relationships between business entities;
- measures, including calculation, aggregation, unit or currency, and time basis where relevant;
- business operations and their intended effect;
- role objectives and permitted capabilities;
- business rules and required approvals;
- required data quality and completeness.
A capability can be technically valid and still be wrong for the business.
For example, Revenue may be available from a certified system while its intended calculation, currency or accounting period is unclear. Customer and Deal may both exist while their business relationship is incorrectly represented.
Those are business-definition failures, not successful production capabilities.
Prove representative business cases
Representative cases prove more than successful requests. The case set should cover the behaviours that matter to the role and the risk of the capability.
Where relevant, cases include:
| Case | What it proves |
|---|---|
| Expected outcome | Normal work produces the approved business result |
| Scope variation | Different identified people receive the correct role- and scope-specific result |
| Missing context | The assistant asks instead of inventing missing information |
| Insufficient data | The assistant does not make a stronger conclusion than the available data supports |
| Denied authority | Prohibited information or operations remain unavailable |
| Approval required | Work waits for the required human or business approval |
| Business-rule boundary | Approved rules remain correct at important boundary conditions |
| Calculation | Measures use the approved definition, aggregation, unit and time basis |
| Cross-system context | Approved relationships produce the expected combined business context |
| Safe stop | Unsafe, ambiguous or out-of-scope work stops correctly |
The required cases depend on the role, business outcome and risk. Not every Role Assistant needs every case type.
No result is not always evidence of absence
Business correctness also depends on whether the available information is sufficient to support the answer.
For example, a search may find no customers in a particular country. If country information is missing from a significant part of the customer data, the correct business behaviour may be to state that the available information is insufficient — not to conclude that no such customers exist.
Where completeness matters to the business outcome, representative cases should prove this behaviour.
Improve and prove again
Prove again when the business changes
Proof applies to an approved version and scope.
Changes to business definitions, relationships, measures, rules, authority, Connected System contracts, Role Assistant configuration, or other behaviour-affecting dependencies can require affected cases to be run again before a new version is approved.
The important asset is the approved business expectation.
A model, integration, or implementation can change while the organisation continues to prove the new version against the same expected business outcome.
This separates business correctness from a particular AI implementation.
Learn from failed proof
A failed case is not automatically a reason to add code.
First determine what failed:
- the approved business definition is incomplete or incorrect;
- the generated candidate did not represent the definition correctly;
- a Connected System capability is incorrect;
- AI behaviour did not meet the expected outcome; or
- a genuinely generic platform capability is missing.
When the problem is incorrect or incomplete business understanding, improve the business specification or generated definition and prove it again.
Do not turn customer-specific business meaning into customer-specific runtime code merely to make a test pass.
This keeps business meaning explicit, inspectable and reusable as the organisation, its systems and its AI implementations change.
Example
Before a Sales Assistant is made available, the CRM and related document capabilities are certified for the intended sales scope.
The generated business definition is then validated. Customer, Contact, Deal and their relationships have the intended business meaning. Relevant measures and operations are correctly described, and the Sales role has the intended capabilities.
Representative cases then prove that an identified account manager can:
- prepare a renewal using the correct customer context;
- receive only information within the permitted scope;
- be asked for missing information rather than receiving an invented answer;
- wait for a required commercial exception;
- avoid overstating conclusions when source information is incomplete; and
- stop safely when a request or operation is outside the permitted boundary.
A successful CRM end-to-end test alone is not that proof.
Business value
Leaders can refuse production until both the enterprise systems and the generated business capability have been proved.
More importantly, approved business expectations become reusable assets. When a model, integration, or implementation changes, teams can prove the new version against the same business expectations instead of redefining correctness for every AI project.
Failed tests can also improve the reusable business definition. When the problem is business understanding, teams improve the specification and generated definition rather than hiding customer-specific corrections in prompts or runtime code.
Certified systems, business context and approved test cases can then carry forward into subsequent Role Assistants.
The result is not simply more AI testing. It is a repeatable way to answer:
Does this approved AI capability still perform the right business work, for the right person, under the right conditions?
Limits
Test depth and human approvals depend on risk, environment and operating policy.
Role Assistant proof does not make probabilistic AI deterministic, and certification does not replace runtime authority checks. Operational Trust continues to enforce the identified person, active Business Role, scope, permitted capabilities and required approvals during execution.
This page does not replace Validation and certification for Connected Systems or the integrator how-tos for commands.
Named-record, service, and document Result projections, and a shared Task Execution details shell, are not claimed live on every deployment. The governed Result itself — one business-readable outcome per completed run — is the contract.