Reference-architecture workshop

Workshop objective

Design a vendor-neutral reference architecture for the synthetic private knowledge assistant. Use the SAI-100 foundation package and SAI-110 threat model as inputs. Do not use customer-sensitive architecture data in a public or shared environment.

Download SAI-120 architecture-decision templateA Markdown ADR with consistent option, control, evidence, consequence, and exit fields.

Step 1: Establish architecture drivers

List intended purpose, prohibited uses, users, data classes, required sovereignty dimensions, high-priority threat scenarios, quality attributes, continuity needs, and accepted constraints.

Rank the drivers. Conflicting requirements should become explicit trade-offs rather than hidden assumptions.

Step 2: Create the context and responsibility model

Draw the system context. Then map the reference-architecture layers to responsibilities and owners. Identify which responsibilities may be combined in one component and which require separation of authority.

Exit check: every material function, decision, and privileged capability has an owner.

Step 3: Define views and interfaces

Produce logical, trust/data-flow, deployment, supply-chain/lifecycle, and operations/evidence views. Number material flows and define their identity, contract, policy, failure behavior, and evidence.

Exit check: names and IDs remain consistent across views.

Step 4: Select deployment patterns

Compare at least two patterns using the same data boundary, administrative authority, artifact supply chain, external dependency, continuity, portability, evidence, skills, and cost questions.

Use Deployment boundaries and patterns.

Step 5: Record material decisions

Create ADRs for deployment boundary, model runtime and routing, knowledge and permissions, artifact supply chain, identity and gateway, evidence, and portability. State limitations and reversal triggers.

Use the ADR structure.

Step 6: Place controls and evidence

Map high-priority control objectives to architecture components and interfaces. Identify preventative, detective, corrective, and recovery controls. Define evidence producers, version identifiers, integrity, storage, retention, and review.

Exit check: controls cannot be bypassed through an unmodelled deployment or administrative path.

Step 7: Test portability and failure

Walk through provider loss, model replacement, unavailable retrieval, denied egress, compromised artifact, capacity exhaustion, evidence-store failure, rollback, and restore. Record expected behavior and required recovery evidence.

Step 8: Create the readiness backlog

For every gap, record requirement, affected view and decision, threat or dependency, owner, priority, completion evidence, and milestone.

Workshop package

Deliver:

1. Architecture-driver register.
2. Context and multi-view diagram set.
3. Layer and responsibility map.
4. Controlled-interface register.
5. Architecture decision-record set.
6. Control and evidence map.
7. Portability, failure, and recovery test plan.
8. Prioritized readiness backlog.

The package supports architecture review; it does not by itself authorize a production deployment.