Foundation architecture workshop

Workshop objective

Apply the SAI-100 method to a synthetic internal knowledge assistant. The workshop produces useful architecture artifacts without deploying production infrastructure or using customer data.

Use synthetic policy documents and fictional identities only.

Download SAI-100 system-definition templateA reusable Markdown worksheet for actors, assets, boundaries, controls, evidence, limitations, and exit triggers.

Scenario

An organization wants an assistant that answers employee questions about internal travel and information-security policies. Answers must cite approved documents. Users may see only documents permitted for their business unit. The runtime should operate inside an approved private environment, and administrators need evidence of the deployed model, index, policies, and blocked requests.

The assistant must not make employment decisions, provide legal advice, or answer from unsupported knowledge.

Step 1: Define the system

Use the Define the AI system template.

Record the owner, intended purpose, approved users, affected parties, inputs, outputs, human responsibility, deployment environment, dependencies, and prohibited uses.

Validation: another person should be able to determine whether a proposed use is inside or outside the approved purpose.

Step 2: Draw context and boundaries

Use Trust boundaries and data flows.

Include the employee, identity provider, application, retrieval service, document sources, index, model runtime, import path, operators, evidence store, and any external dependency. Number every material flow.

Validation: every path by which data, artifacts, administration, or evidence enters or leaves the runtime is visible.

Step 3: Write control objectives

Create at least one testable objective for each foundation family:

• Purpose and ownership.
• Data and permissions.
• Model and prompt versions.
• Artifact supply chain.
• Input, output, and egress.
• Operations and recovery.
• Evidence and review.

Use the control-objective pattern.

Validation: each objective states scope, owner, required outcome, and verification method.

Step 4: Create the evidence map

Select the five objectives with the highest impact. For each, identify the evidence producer, version identifiers, storage boundary, integrity mechanism, retention, and review trigger.

Use Evidence by design.

Validation: a reviewer can connect the evidence to the system version and determine whether the control operated.

Step 5: Record dependencies and trade-offs

Create a short sovereignty profile across data, model, infrastructure, operations, and evidence. For every accepted external dependency, record the rationale, outage or change impact, alternative, and owner.

Validation: the profile does not use a single unsupported “sovereign” rating.

Step 6: Build the readiness backlog

Convert gaps into actionable work:

Backlog item:
Risk or required outcome:
Affected boundary and component:
Owner:
Priority:
Dependency:
Completion evidence:
Target milestone:

Separate items needed before a pilot from later production-hardening work.

Completion package

The workshop is complete when the package contains:

1. One-page system definition.
2. Context and trust-boundary diagram with numbered flows.
3. Control-objective register covering all seven families.
4. Evidence map for the five highest-impact controls.
5. Sovereignty-dimension profile and accepted dependencies.
6. Prioritized readiness backlog.

This is an educational foundation package, not a production approval or compliance assessment.