Author Role Assistant Evidence

Add Evidence to a Role Assistant package so governed asks, gates, and expected behaviors promote with upload — without storing vendor schemas as Evidence. Evidence is the business-significant layer that shapes how work continues; it is not current Reality and not Knowledge answers.

Why this matters: You do not encode the process as a workflow graph. You publish the asks, gates, and expected behaviors that make governed continuation testable — so the Runtime can decide from what matters in the business, and you can prove the assistant still respects that process. The platform certifies Evidence: it rejects duplicates and Evidence that excludes each other, so the process can still complete.

Prerequisites

• Role Assistant package on disk (Manage Role Assistant packages)
• Understanding that Evidence is not current Reality and not filled answers
• Concept background: Evidence Fabrix
• Optional: plan how you will prove asks after promote — Test Role Assistants

Where it lives

Evidence holds question templates, confidence gates, and business-significant conditions. Filled answers and vendor substance belong in Knowledge (Author Role Assistant Knowledge).

Ownership reminder:

Vendor operation or schema fact = Knowledge
Vendor mapping and joins         = CIP
Canonical enterprise meaning     = COM
Current authorized business fact = Reality
Business-significant condition   = Evidence

How to set

1. Read live Evidence metadata (allowed kinds, aspects, resources, capabilities) before inventing fields. Reuse existing patterns. Do not author duplicates or rows that exclude each other for the same situation — certification will reject them so the process stays completable.

2. Author rows under package evidence/ with specific when conditions and actionable expected behavior. Align kind, aspect, and resource type with what the platform supports. Each row must leave a path for work to finish (ask, wait, or continue) — not a dead-end that contradicts another certified gate.

   Kind defaults are not value generated. Selecting an Evidence Kind may show expected contribution vocabulary for that kind. That is catalog guidance — it does not create a realized contribution value until governed outcomes attribute one. Do not invent free-form vendor field names as contribution types.

Illustrative row shape (fields vary by deployment — validate against Evidence contracts):

kind: missing_information
aspect: connected-system-authoring
resourceType: customer
when: "Primary customer identity is ambiguous across more than one candidate record"
expectedBehavior: "Ask a constrained clarification before create or update; do not invent the primary key"

3. Keep boundaries

Questions and gates → Evidence
Filled answers / substance → Knowledge
Vendor mappings / joins → CIP / COM (not Evidence)
Current facts → Reality

4. Promote with the package:

aifabrix validate <roleKey>
aifabrix upload <roleKey> --env dev

Upload discovers evidence/, then load → validate → certify → production-ready. Certification covers the set as a whole: duplicate or mutually exclusive Evidence fails required checks. Required failures exit non-zero. Do not treat partial production-ready as silent success.

5. Extend a missing ask: add Evidence for the new closed key, document the key in your question catalog, store answers as Knowledge — do not invent free-text question surfaces in product code.

6. Standalone path (optional): Builder aifabrix evidence list/get/insert/load when you need CRUD outside package promote.

aifabrix evidence list --role-key sales-representative
aifabrix evidence load ./evidence-batch.json --dry-run

Defaults and examples

Good (shape):

• when: Customer identity confidence is below policy threshold for ownership change.
• expectedBehavior: Pause the change, request secondary verification, require human approval.

Bad:

• when: When needed.
• expectedBehavior: Handle correctly.

Ambiguity handling: flag uncertainty, ask a focused human question, keep candidate Evidence inactive until reviewed.

Validate

If upload fails on Evidence, fix or remove invalid rows under evidence/ and re-upload. Do not bypass required Evidence failures.

Common mistakes

Limits

• Exact Evidence JSON fields follow dataplane Evidence Fabrix contracts and your Builder version.
• Activation and certification details can vary by deployment — confirm with upload summary and Evidence CLI help.
• Category B enterprise capability language is synthesized from Connected Systems, not authored as a predetermined Builder catalogue.
• This page does not create Role Assistants from scratch — assistants remain platform-generated.

Related

• Evidence Fabrix
• Manage Role Assistant packages
• Author Role Assistant Knowledge
• Test Role Assistants
• CLI reference