# SCALE Analysis Workspace Workbook

**Strategic Capabilities Architecture Linkage Engine · Portable AI agent kit · Version 0.5 · August 2026**

Use this workbook to begin with a business question, assemble governed evidence, develop the relevant architecture, perform an analysis, create a decision-focused work product, and carry accepted knowledge forward. The business architect is the primary user and owns the analysis and resulting architecture. SCALE proposes, traces, compares, challenges, and assists; accountable people validate meaning and retain formal decision rights.

This workbook is included in the SCALE Portable Agent Kit. When used with SCALE-AGENT-INSTRUCTIONS.md, the AI maintains these registers conversationally and returns them through EXPORT WORKSPACE. The workbook may also be used manually without an AI.

Complete only the sections needed for the current analysis. Do not begin with enterprise-wide ingestion, platform selection, or a general request to discover what AI can find.

## 1. Analysis workspace charter

| Field | Entry |
|---|---|
| Workspace or engagement name |  |
| Lead business architect |  |
| Accountable decision owner or forum |  |
| Business question |  |
| Decision or action this work will support |  |
| Audience |  |
| Decision date or review point |  |
| Relevant time horizon |  |
| Value at stake |  |
| Authorized scope |  |
| Required work product |  |
| Architecture steward |  |
| SCALE product owner |  |
| Evidence and content owners |  |
| Risk or security reviewer, if required |  |
| Workspace start date |  |
| First formal review date |  |
| Ongoing review cadence |  |

### Working purpose

> SCALE will help the lead business architect understand **[business question]** by connecting **[authorized enterprise evidence]**, developing or reusing **[relevant architecture]**, and preparing **[work product]** for **[decision owner or forum]** before **[decision point]**.

### Sufficiency condition

> The analysis is sufficient when **[named audience]** can understand **[findings, implications, options, confidence, and unresolved matters]** well enough to make or prepare **[named decision or action]**.

### Stop or redesign condition

> Stop or redesign the analysis if **[critical evidence, access, authority, ownership, traceability, value, or maintenance condition]** is not met by **[date or review point]**.

## 2. Choose the entry path

Select one primary path. Add secondary paths only when they are necessary to answer the same business question.

- [ ] **Assess an initiative:** understand affected capabilities, value streams, organizations, information, stakeholders, dependencies, and outcomes.
- [ ] **Explore a strategy:** trace strategic intent into the parts of the enterprise required to execute it.
- [ ] **Analyze a change:** identify impacts, gaps, dependencies, constraints, and unresolved architecture questions.
- [ ] **Build architecture:** develop or extend capability, value-stream, organization, information, stakeholder, strategy, and initiative views.
- [ ] **Create a work product:** use existing architecture and evidence to prepare a decision-focused assessment, brief, heatmap, or cross-map.

### Use-case screen

| Question | Response |
|---|---|
| What cannot be answered reliably through ordinary document search? |  |
| Which enterprise relationships must be traversed? |  |
| What material uncertainty or conflict must remain visible? |  |
| Which existing architecture can be reused? |  |
| What new architecture may need to be proposed? |  |
| Who can validate the business meaning? |  |
| Who has formal authority to decide? |  |
| What should persist after this analysis concludes? |  |

### Disqualifying conditions

Pause or redesign when any of the following is true:

- [ ] Ordinary search or a conventional workshop can answer the question adequately
- [ ] No accountable decision, action, or work product can be named
- [ ] No business architect is available to own the analysis
- [ ] Necessary evidence cannot be accessed lawfully or securely
- [ ] No content owner or steward will validate material architecture proposals
- [ ] The work assumes that an AI response becomes approved enterprise truth
- [ ] The requested outcome requires autonomous architecture, policy, or investment authority
- [ ] The organization cannot maintain the accepted architecture

## 3. Decision and question set

| ID | Business question | Decision relevance | Audience | Time horizon | Required evidence | Sufficient answer | Priority |
|---|---|---|---|---|---|---|---|
| Q-01 |  |  |  |  |  |  |  |
| Q-02 |  |  |  |  |  |  |  |
| Q-03 |  |  |  |  |  |  |  |
| Q-04 |  |  |  |  |  |  |  |
| Q-05 |  |  |  |  |  |  |  |

### Required question variants

For each material question, test the variants that apply:

- [ ] Current-state fact
- [ ] Target-state intent
- [ ] Impact if a change proceeds
- [ ] Exposure if a change slips or stops
- [ ] Upstream dependency
- [ ] Downstream dependency
- [ ] Overlap or duplication
- [ ] Ownership and decision rights
- [ ] Conflict, gap, or stale knowledge
- [ ] Prior decision and applicable rationale
- [ ] Evidence that is missing or inaccessible

## 4. Architecture boundary

| Domain | Included scope | Excluded scope | Why needed for the question | Owner or steward | Existing source | Required maturity |
|---|---|---|---|---|---|---|
| Strategy and outcomes |  |  |  |  |  |  |
| Stakeholders and value |  |  |  |  |  |  |
| Value streams and stages |  |  |  |  |  |  |
| Capabilities |  |  |  |  |  |  |
| Information and business objects |  |  |  |  |  |  |
| Organization and decision rights |  |  |  |  |  |  |
| Initiatives and investments |  |  |  |  |  |  |
| Policies, rules, measures, and risks |  |  |  |  |  |  |
| Products, services, and customer propositions |  |  |  |  |  |  |
| Applications and other enablement |  |  |  |  |  |  |
| Prior decisions and exceptions |  |  |  |  |  |  |

### Boundary rules

- Include a domain only when the business question requires it.
- Prefer a visible gap over an unsupported relationship.
- Record exclusions so later users do not mistake absence for irrelevance.
- Preserve scenario, business-unit, geography, product, and time qualifiers.
- Do not make every domain complete before the current analysis can proceed.

## 5. Evidence and authority register

Preserve an existing governed evidence identifier. Allocate a local `E-*` identifier only when the source has none; keep file or section locators separate from evidence identity.

| Evidence ID | Source or record | Source owner | Authority level | Effective date | Review date | Access class | Relevant claim or relationship | Conflict or limitation | Disposition |
|---|---|---|---|---|---|---|---|---|---|
| E-001 |  |  |  |  |  |  |  |  |  |
| E-002 |  |  |  |  |  |  |  |  |  |  |
| E-003 |  |  |  |  |  |  |  |  |  |  |
| E-004 |  |  |  |  |  |  |  |  |  |

### Source disposition

For each source, select one:

- **Governed authority:** use as the authoritative record for the stated scope and period.
- **Linked authority:** keep the source in its native system and link to it.
- **Synchronized attribute:** copy only named attributes under an explicit synchronization rule.
- **Supporting evidence:** use as evidence without treating it as the system of record.
- **Context only:** use to frame interpretation, not to support enterprise facts.
- **Excluded:** do not retrieve or use for the analysis.

## 6. Architecture element register

| Element ID | Type | Name | Definition | Status | Owner or steward | Source | Effective dates | Confidence | Access class | Review date |
|---|---|---|---|---|---|---|---|---|---|---|
| EL-001 |  |  |  |  |  |  |  |  |  |  |
| EL-002 |  |  |  |  |  |  |  |  |  |  |
| EL-003 |  |  |  |  |  |  |  |  |  |  |
| EL-004 |  |  |  |  |  |  |  |  |  |  |

### Element quality checks

- [ ] Stable identifier
- [ ] Governed type
- [ ] Clear name and definition
- [ ] Status and effective period
- [ ] Owner or steward
- [ ] Source and evidence
- [ ] Confidence and review date
- [ ] Access classification
- [ ] Version and change history
- [ ] Scenario or scope qualifier where required

## 7. Architecture relationship register

| Relationship ID | Source element | Relationship type | Target element | Status | Evidence IDs | Confidence | Owner | Effective dates | Scenario or scope | Review date |
|---|---|---|---|---|---|---|---|---|---|---|
| RL-001 |  |  |  |  |  |  |  |  |  |  |
| RL-002 |  |  |  |  |  |  |  |  |  |  |
| RL-003 |  |  |  |  |  |  |  |  |  |  |
| RL-004 |  |  |  |  |  |  |  |  |  |  |

### Relationship quality checks

- [ ] Direction is explicit
- [ ] Relationship type is governed
- [ ] Source and target identifiers exist
- [ ] Evidence supports the stated relationship
- [ ] Fact and inference are distinguishable
- [ ] Confidence has a recorded basis
- [ ] Owner and effective dates are present
- [ ] Scenario and scope qualifiers are preserved
- [ ] Competing relationships remain visible
- [ ] Access rules cover the relationship and its evidence

## 8. SCALE proposal review queue

Record every material concept, relationship, finding, correction, or work-product recommendation proposed by SCALE.

| Proposal ID | Proposal | Type | Evidence path | Classification | Confidence | Architect disposition | Required change | Reviewer | Rationale | Date |
|---|---|---|---|---|---|---|---|---|---|---|
| PR-001 |  |  |  |  |  | Accept / Modify / Reject / Investigate |  |  |  |  |
| PR-002 |  |  |  |  |  | Accept / Modify / Reject / Investigate |  |  |  |  |
| PR-003 |  |  |  |  |  | Accept / Modify / Reject / Investigate |  |  |  |  |

### Review rules

- **Accept:** evidence and semantics are sufficient for the stated scope.
- **Modify:** the proposal is useful but requires a corrected definition, relationship, qualifier, confidence, or source.
- **Reject:** the proposal is unsupported, incorrect, irrelevant, or outside scope.
- **Investigate:** the proposal is material but requires additional evidence or accountable review.

No proposal becomes governed architecture solely because SCALE generated it.

## 9. Analysis log

| Analysis ID | Question ID | Traversal or comparison performed | Finding | Classification | Evidence path | Confidence | Conflict or gap | Implication | Next action |
|---|---|---|---|---|---|---|---|---|---|
| AN-001 |  |  |  | Fact / Inference / Assumption / Recommendation / Conflict |  |  |  |  |  |
| AN-002 |  |  |  | Fact / Inference / Assumption / Recommendation / Conflict |  |  |  |  |  |
| AN-003 |  |  |  | Fact / Inference / Assumption / Recommendation / Conflict |  |  |  |  |  |

## 10. Work-product plan

| Field | Entry |
|---|---|
| Work-product type |  |
| Decision or action supported |  |
| Primary audience |  |
| Required architecture views |  |
| Required findings |  |
| Required options or scenarios |  |
| Required confidence and caveats |  |
| Decisions or approvals still needed |  |
| Delivery format |  |
| Owner |  |
| Due date |  |

### Candidate work products

- [ ] Impact assessment
- [ ] Initiative decomposition
- [ ] Strategy-to-execution view
- [ ] Capability assessment or heatmap
- [ ] Value-stream and capability cross-map
- [ ] Modernization analysis
- [ ] Operating-model view
- [ ] Stakeholder or organization view
- [ ] Information or business-object view
- [ ] Architecture brief
- [ ] Decision record
- [ ] Other: **[name]**

## 11. Provenance and answer contract

### Decision context

- **Question:**
- **Decision owner or audience:**
- **Scope:**
- **Scenario and time horizon:**
- **Sufficiency criteria:**

### Direct finding

State the smallest useful answer.

### Architecture path

Record the typed path followed.

> **[Element]** → **[relationship]** → **[element]** → **[relationship]** → **[element]**

### Evidence

| Claim or relationship | Evidence ID | Source authority | Effective date | Access confirmed | Notes |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

### Conflicts, gaps, and stale knowledge

- **Conflict:**
- **Missing evidence:**
- **Stale record:**
- **Unresolved owner:**
- **Inaccessible evidence:**

### Confidence

- **Overall confidence:** High / Medium / Low / Insufficient
- **Basis:** source authority, freshness, agreement, completeness, traversal quality, and human review.

### Remaining judgment and next governed action

- **Decision still required:**
- **Authorized owner or forum:**
- **Recommended next action:**
- **Required review or escalation:**

## 12. Governance and decision rights

| Decision or action | Lead business architect | Business owner | BA steward | SCALE product owner | Knowledge engineer | Risk or security | Forum or escalation |
|---|---|---|---|---|---|---|---|
| Approve analysis scope |  |  |  |  |  |  |  |
| Validate element definitions |  |  |  |  |  |  |  |
| Validate relationship semantics |  |  |  |  |  |  |  |
| Accept evidence authority |  |  |  |  |  |  |  |
| Resolve conflicting records |  |  |  |  |  |  |  |
| Approve architecture change |  |  |  |  |  |  |  |
| Approve work-product release |  |  |  |  |  |  |  |
| Accept business decision |  |  |  |  |  |  |  |
| Approve access exception |  |  |  |  |  |  |  |
| Retire stale architecture |  |  |  |  |  |  |  |

## 13. Correction, override, and exception log

| Record ID | Type | Related proposal, finding, element, or relationship | Human disposition | Rationale | Owner | Required correction | Due date | Status | Closed date |
|---|---|---|---|---|---|---|---|---|---|
| GOV-001 | Correction / Override / Exception / Escalation |  |  |  |  |  |  |  |  |
| GOV-002 | Correction / Override / Exception / Escalation |  |  |  |  |  |  |  |  |

## 14. Maintenance and reuse plan

| Architecture item | Carry forward? | Governing source | Steward | Review trigger | Review date | Reuse scenarios | Retirement condition |
|---|---|---|---|---|---|---|---|
|  | Yes / No / Investigate |  |  |  |  |  |  |
|  | Yes / No / Investigate |  |  |  |  |  |  |
|  | Yes / No / Investigate |  |  |  |  |  |  |

### Continuity checks

- [ ] Accepted concepts and relationships have named stewards
- [ ] Evidence paths remain linked to their source authority
- [ ] Effective dates and review dates are recorded
- [ ] Unresolved conflicts and gaps remain visible
- [ ] Human dispositions and rationale are retained
- [ ] Later analyses can identify which knowledge is reusable
- [ ] Superseded or rejected architecture can be distinguished from current architecture
- [ ] Maintenance demand fits named organizational capacity

## 15. Operating measures

| Measure | Baseline | Target or expectation | Current result | Evidence | Owner | Review date | Action |
|---|---|---|---|---|---|---|---|
| Material claim traceability |  | Every enterprise fact has a governed record or cited source |  |  |  |  |  |
| Unsupported claim rate |  | Zero in accepted work products |  |  |  |  |  |
| Architecture review quality |  | Material proposals receive a named human disposition and rationale |  |  |  |  |  |
| Conflict and gap detection |  | Material stale, missing, and contradictory records remain visible |  |  |  |  |  |
| Access-control fidelity |  | No answer, citation, inference, or export exceeds source permissions |  |  |  |  |  |
| Decision effort |  | Reduced effort to assemble and explain governed evidence |  |  |  |  |  |
| Architecture reuse |  | Accepted knowledge supports additional questions with provenance intact |  |  |  |  |  |
| Maintenance closure |  | Material corrections and reviews close within named expectations |  |  |  |  |  |
| Decision support |  | Named decisions are improved, accelerated, reframed, resequenced, or stopped |  |  |  |  |  |

## 16. Analysis completion and continuation review

### Work delivered

- **Business question answered:**
- **Work product delivered:**
- **Decision or action supported:**
- **Decision owner response:**

### Architecture developed

- **Elements accepted:**
- **Relationships accepted:**
- **Evidence paths established:**
- **Conflicts or gaps retained:**
- **Corrections completed:**

### Knowledge carried forward

- **Reusable architecture:**
- **Named stewards:**
- **Next review triggers:**
- **Adjacent questions now supportable:**

### Residual risks

| Risk | Consequence | Owner | Treatment | Due date | Status |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

### Recommended disposition

- [ ] Continue maintenance within the current scope
- [ ] Extend the workspace to an adjacent decision or architecture domain
- [ ] Redesign the knowledge model, evidence boundary, permissions, or workflow
- [ ] Narrow the supported question set
- [ ] Pause until ownership, evidence, authority, or capacity is resolved
- [ ] Retire the workspace because continuing cost exceeds decision value

### Rationale and authority

- **Recommendation:**
- **Evidence supporting the recommendation:**
- **Business architect:**
- **Accountable owner or forum:**
- **Decision date:**
- **Next review date:**

## Final operating rule

An analysis is complete when the required decision support has been delivered and its material findings can be inspected. The architecture continues only when accepted knowledge has identifiable evidence, human disposition, named stewardship, access controls, and a credible maintenance path. Expand because governed reuse and decision demand justify it, not because the interface produced an impressive response.