# SCALE Pilot Workbook

**Strategic Capabilities Architecture Linkage Engine · Business architecture tool · Version 0.3 · August 2026**

Use this workbook to frame, govern, test, and decide a bounded, BA-led SCALE pilot. SCALE is designed primarily for the business architect, who frames the inquiry, curates the relevant business architecture linkages, evaluates the returned evidence, and prepares decision support for the accountable owner. Complete only the sections needed for the selected decision scenario. Do not begin with enterprise-wide ingestion or platform selection.

## 1. Pilot charter

| Field | Working entry |
|---|---|
| Pilot name |  |
| Executive or business decision owner |  |
| Lead business architect (primary user and pilot lead) |  |
| SCALE product owner |  |
| Business architecture steward |  |
| Decision to improve |  |
| Decision date or cadence |  |
| Secondary users or decision audiences |  |
| Selected value stream |  |
| Scope boundary |  |
| Explicit non-scope |  |
| Current decision process |  |
| Baseline time and effort |  |
| Expected value |  |
| Required access classification |  |
| Pilot start date |  |
| Scale, redesign, or stop review date |  |

### Pilot purpose

> SCALE will help the lead business architect investigate **[business question]** by traversing **[governed business architecture scope]** and preparing **[required answer, evidence, implications, and options]** for **[decision owner or forum]** before **[decision point]**.

### Stop condition

> Stop or redesign the pilot if **[critical traceability, access, ownership, value, or maintenance condition]** is not met by **[date or gate]**.

## 2. Use-case screen

Score each dimension from 0 to 3. A high total does not override a critical governance or access failure.

| Dimension | 0 | 1 | 2 | 3 | Score |
|---|---|---|---|---|---|
| Decision importance | Informational only | Local low-impact | Material recurring decision | Enterprise or high-consequence decision |  |
| Relationship depth | Document lookup | One direct link | Several linked domains | Multi-domain impact or dependency path |  |
| Recurrence | One time | Occasional | Monthly or quarterly | Frequent or reused across decisions |  |
| Knowledge readiness | Unknown or unavailable | Mostly unstructured | Partly governed | Stable identity, sources, and owners |  |
| BA and owner availability | No lead BA or owner | Interested BA or contact | Named lead BA and content owner | Named lead BA, decision owner, and stewards |  |
| Evaluation readiness | No known answer | Subjective review only | Some known cases | Acceptance set and baseline available |  |
| Access feasibility | Unresolved restriction | Material uncertainty | Manageable controls | Clear role-based access |  |
| Learning value | Little reusable learning | Tool learning only | Reusable retrieval pattern | Reusable operating and governance pattern |  |

**Total:** ____ / 24

### Disqualifying conditions

- [ ] No lead business architect is available to operate and evaluate the pilot
- [ ] No accountable decision or content owner
- [ ] Source permissions cannot be preserved
- [ ] The question can be answered adequately with ordinary search
- [ ] The pilot requires autonomous decision authority
- [ ] The knowledge cannot be maintained after the demonstration
- [ ] No acceptance set or credible evaluation method can be established

**Disposition:** Proceed / Narrow / Redesign / Defer / Stop

**Rationale:**

## 3. Decision and question set

Create 10–20 questions that reflect real business architecture work. The lead BA should own the question set and include known straightforward questions, cross-domain questions, missing-data cases, conflicts, stale records, and access restrictions.

| ID | Question | Decision supported | Business architect user | Expected architecture path | Expected sources | Required classification | Owner |
|---|---|---|---|---|---|---|---|
| Q-01 |  |  |  |  |  |  |  |
| Q-02 |  |  |  |  |  |  |  |
| Q-03 |  |  |  |  |  |  |  |
| Q-04 |  |  |  |  |  |  |  |
| Q-05 |  |  |  |  |  |  |  |

### Required question variants

- [ ] Direct factual retrieval
- [ ] Strategy-to-capability linkage
- [ ] Initiative impact or dependency
- [ ] Portfolio overlap or gap
- [ ] Ownership and decision rights
- [ ] Business-object lifecycle
- [ ] Policy or risk constraint
- [ ] Prior decision and institutional memory
- [ ] Known contradiction
- [ ] Known stale record
- [ ] Missing owner or relationship
- [ ] Inaccessible source or restricted relationship

## 4. Knowledge-slice boundary

| Domain | Included scope | Excluded scope | Why required | Content owner |
|---|---|---|---|---|
| Strategy and outcomes |  |  |  |  |
| Stakeholders and value |  |  |  |  |
| Value stream and stages |  |  |  |  |
| Capabilities |  |  |  |  |
| Business objects |  |  |  |  |
| Organization and decision rights |  |  |  |  |
| Policies, rules, and risks |  |  |  |  |
| Initiatives and dependencies |  |  |  |  |
| Measures |  |  |  |  |
| Applications and technology |  |  |  |  |
| Decisions and sources |  |  |  |  |

## 5. Element register

| ID | Type | Name | Definition | Level | Status | Owner or steward | Source | Effective date | Review date | Confidence | Access |
|---|---|---|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |  |  |  |

### Element quality checks

- [ ] Stable identifier exists
- [ ] Name and definition are distinct and business meaningful
- [ ] Type and level follow the local modeling rules
- [ ] Current, proposed, historical, and retired states are separated
- [ ] Alias and duplicate decisions are recorded
- [ ] Owner or steward is an authorized role
- [ ] Source authority is known
- [ ] Effective and review dates are usable
- [ ] Confidence has an evidence-based rationale
- [ ] Access classification is assigned

## 6. Relationship register

| ID | Source ID | Relationship | Target ID | Scenario or scope | Status | Evidence | Owner | Effective date | Review date | Confidence | Access |
|---|---|---|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |  |  |  |

### Relationship quality checks

- [ ] Direction and meaning are explicit
- [ ] Source and target identifiers resolve
- [ ] Relationship type supports a recurring question
- [ ] Scenario or local-variation conditions are recorded
- [ ] Evidence supports the relationship itself
- [ ] Owner and lifecycle are assigned
- [ ] Confidence is not inherited automatically from the nodes
- [ ] Sensitive inference and access implications are assessed

## 7. Source and authority register

| Source ID | Title or system | Record type | Authority | Owner | Effective period | Access | Retrieval method | Retention | Known limitations |
|---|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |  |

### Source disposition

| Content type | Govern natively in SCALE | Link to authority | Synchronize attribute | Use as evidence only | Exclude |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 8. Access and policy design

| Role | Allowed domains | Restricted domains | Relationship restrictions | Citation rules | Export rules | Mandatory review |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

### Access tests

- [ ] User cannot retrieve an inaccessible source record
- [ ] User cannot receive a restricted source passage in a citation
- [ ] User cannot infer a restricted fact through an exposed relationship
- [ ] Export preserves source and relationship restrictions
- [ ] Logs do not expose content beyond administrator authority
- [ ] Policy-sensitive questions route to the required reviewer
- [ ] Model provider and hosting pattern are approved for the classification

## 9. Answer contract template

### Decision context

- **Question:**
- **Decision owner:**
- **Audience:**
- **Scenario:**
- **Time horizon:**
- **Scope:**

### Direct answer


### Architecture path

1. 
2. 
3. 

### Evidence

| Claim | Classification | Governed record | Source passage | Effective date | Access | Confidence |
|---|---|---|---|---|---|---|
|  | Fact / Inference / Assumption / Recommendation / Conflict / Unknown |  |  |  |  |  |

### Conflicts, gaps, and stale knowledge


### Remaining decision and owner


### Next governed action


## 10. Known-answer acceptance set

| Question ID | Expected direct answer | Required path | Required evidence | Known conflict or gap | Forbidden claim | Reviewer |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

### Seeded challenge cases

| Case ID | Challenge | Expected system behavior | Result | Defect owner |
|---|---|---|---|---|
| C-01 | Stale ownership record | Expose stale status and identify resolution owner |  |  |
| C-02 | Contradictory definitions | Present conflict without silent reconciliation |  |  |
| C-03 | Missing relationship | State unknown and avoid invented linkage |  |  |
| C-04 | Restricted source | Withhold content and explain access limitation safely |  |  |
| C-05 | Similar but unrelated document | Reject similarity as proof of enterprise linkage |  |  |
| C-06 | Proposed target represented as current | Preserve lifecycle distinction |  |  |

## 11. Evaluation scorecard

Set thresholds before testing.

| Measure | Baseline | Target | Actual | Evidence | Disposition |
|---|---:|---:|---:|---|---|
| Material claim traceability |  |  |  |  |  |
| Unsupported claim rate |  | 0 |  |  |  |
| Known-answer acceptance |  |  |  |  |  |
| Conflict and gap detection |  |  |  |  |  |
| Access-control fidelity |  | 100% |  |  |  |
| Median decision-support effort |  |  |  |  |  |
| Correction turnaround |  |  |  |  |  |
| Knowledge reuse |  |  |  |  |  |
| Decisions improved |  |  |  |  |  |
| Stewardship effort |  |  |  |  |  |

## 12. Governance and decision rights

| Decision | Lead business architect | Business owner | BA steward | SCALE product owner | Knowledge engineer | Risk or security | Forum or escalation |
|---|---|---|---|---|---|---|---|
| Approve pilot scope |  |  |  |  |  |  |  |
| Approve canonical definition |  |  |  |  |  |  |  |
| Approve relationship |  |  |  |  |  |  |  |
| Change owner or status |  |  |  |  |  |  |  |
| Approve access classification |  |  |  |  |  |  |  |
| Accept policy-sensitive answer |  |  |  |  |  |  |  |
| Approve writeback |  |  |  |  |  |  |  |
| Accept residual risk |  |  |  |  |  |  |  |
| Scale, redesign, pause, or stop |  |  |  |  |  |  |  |

## 13. Correction, override, and exception log

| ID | Date | Question or record | Type | Description | Decision owner | Rationale | Disposition | Expiry or review | Resulting change |
|---|---|---|---|---|---|---|---|---|---|
|  |  |  | Correction / Override / Exception / Conflict |  |  |  |  |  |  |

## 14. Ninety-day work plan

| Phase | Required output | Owner | Due | Gate decision | Status |
|---|---|---|---|---|---|
| Weeks 1–2: Frame | Charter, question set, baseline, access boundary, stop criteria | Lead business architect |  | Proceed / Narrow / Stop |  |
| Weeks 3–5: Govern | Element, relationship, source, owner, confidence, and access registers | Lead BA + content owners |  | Build / Repair / Stop |  |
| Weeks 6–8: Build | Graph, index, orchestration, answer contract, citations, workflow | Knowledge engineer + lead BA |  | Test / Repair / Stop |  |
| Weeks 9–10: Challenge | Acceptance results, security tests, defects, corrections | Lead BA + reviewers |  | Accept / Remediate / Stop |  |
| Weeks 11–13: Decide | Evaluation, operating model, residual risks, recommendation | Lead BA + decision owner |  | Scale / Narrow / Redesign / Pause / Stop |  |

## 15. Operating model readiness

- [ ] The business architect remains the primary user and has capacity to operate the service
- [ ] The business architect owns question framing, architecture interpretation, response review, and decision-support preparation
- [ ] The business decision owner remains accountable for the decision and consequences
- [ ] Business architecture content owners and stewards accept the maintenance duty
- [ ] SCALE product ownership and operating funding are named, normally within or accountable to the BA practice
- [ ] Platform and integration support are named
- [ ] Risk, security, privacy, records, and legal controls are approved
- [ ] Correction and incident service levels are realistic
- [ ] Evaluation continues after the demonstration
- [ ] Expansion thresholds are explicit
- [ ] Retention and retirement are defined
- [ ] The lead BA and secondary users understand facts, inferences, assumptions, recommendations, conflicts, and unknowns

## 16. Final pilot review

### Evidence summary


### Decisions improved


### Trust and access results


### Governance and maintenance burden


### Residual risks


### Recommended disposition

- [ ] Scale to an adjacent decision scenario
- [ ] Narrow the current scope
- [ ] Redesign the knowledge model or retrieval pattern
- [ ] Repair governance before continuing
- [ ] Pause pending evidence, access, ownership, or funding
- [ ] Stop and preserve the validated architecture knowledge

### Rationale


### Decision owner and date


## 17. Final stop condition

Stop the pilot when the governing authority can decide whether the service produces enough traceable decision value to justify its continuing ownership, risk, cost, and stewardship burden. Do not expand because the demonstration is impressive. Expand only when the organization can govern the knowledge and sustain the operating model.