Skip to content

Example: Supplier onboarding

This is a buyer-side governance example. Use Commercial delivery for the supplier-side proposal and economics. First-time operators should follow How to use JAI before adapting this shorter scenario.

Example: Supplier onboarding

Scenario

A business unit wants to procure a SaaS platform quickly. Procurement has a commercial proposal, but architecture, security, privacy, resilience, exit and service-acceptance concerns are incomplete.

Starting material

Provide business requirements, supplier proposal/RFP response, DPA/security material, subprocessor list, service commitments, architecture/interface material, pricing/TCO assumptions and intended data classes.

Run this scenario in the provider CLI

Paste the following as a request in Claude Code or Codex CLI. It is not a terminal command, and it does not automatically authorise tool execution or a business decision:

Assess the proposed SaaS supplier using supplier-onboarding and source-to-contract-to-service. Map contractual obligations, security/privacy evidence, exit risks, integrations and the residual decisions for our service and risk owners.

You: provide the starting material listed above, identify the accountable owners, inspect the evidence and respond to real approval gates. For material decisions, explicitly initiate /layered <intent> in Claude or $workflow-layered <intent> in Codex rather than assuming a natural-language router enforced Fabric. Codex cannot execute protected L0 authority commands: it must show the exact command for you to run separately in a trusted terminal.

Behind the scenes: The agent coordinates sourcing, architecture, GRC and service-readiness reviews. Binding commercial commitments, risk exceptions and supplier/service acceptance belong to the authorised business owners. A named workflow or domain tool is invoked by the provider within its available permissions; its presence in the package is not execution evidence. Ask for exact artefact IDs, failed gates, source references and unresolved decisions.

End-to-end AI IT House process

1. QualifyClarify business need and mandatory requirements.
2. AssessRun architecture, security, privacy and supplier-risk assessment.
3. ContractTranslate unresolved controls into enforceable clauses.
4. ImplementTrack integration, access, monitoring and operational readiness.
5. AcceptRequire service-acceptance evidence before declaring onboarding complete.

1. Frame the engagement

Before generating deliverables, establish the decision, scope, owners and source material. AI IT House should state what it knows, what it is assuming and what is still missing.

2. Route to the correct workflow and roles

Use the named workflow or ask the router to select the relevant specialists. The expected result is not a list of personas, but explicit responsibility for analysis, authoring, review, approval and hand-over.

3. Build the semantic work product

Generate or update the structured architecture, risk, design, operational or decision content. Keep claims tied to evidence and retain unresolved questions rather than silently filling them.

4. Review and close evidence gaps

Run an independent review before publication or approval. Findings should identify severity, evidence, owner and the condition for closure. If the decision is consequential, use the Justifiable Fabric to preserve the review and authority chain.

5. Publish, approve and hand over

Only after semantic review should the output be projected into a stakeholder-facing artefact. Publication may improve communication; it must not invent new decisions.

Example interaction sequence

Apply the source-to-contract-to-service workflow to this SaaS purchase.
Route each step to the correct role and identify missing evidence.

/review supplier-assessment/
/publish supplier-decision.json decision-paper docx,pdf

Illustrative checkpoints and expected output

Pre-signature gate: FAIL
- subprocessor location evidence missing
- RTO commitment not contractually enforceable
- privileged support access model not accepted

Pre-service-acceptance gate: PENDING
- monitoring integration
- CMDB/service ownership
- tested exit/export procedure

Expected artefacts

  • requirement baseline
  • architecture fit assessment
  • security/privacy assurance
  • supplier risk statement
  • required contract clauses
  • service acceptance checklist
  • exit/data-return obligations

Why this example matters

The process prevents “vendor selected” from being confused with “service safe and operationally accepted”.