# SCALE: Strategic Capabilities Architecture Linkage Engine

**Portable AI agent kit and open reference architecture · Version 0.5 · August 2026**

## 1. Purpose

SCALE is a vendor-neutral, portable Business Architecture agent kit and reference architecture for turning governed enterprise evidence into structured architecture, analysis, work products, and traceable decision support. Its primary user and operator is the business architect. The production distribution is loaded into an AI environment selected and approved by the user; it does not require a hosted SCALE service.

The business architect uses SCALE to begin with a strategy, initiative, decision, problem, or change; assemble the relevant evidence; develop or reuse the necessary architecture; investigate typed relationships; and prepare a traceable work product for an accountable decision owner. Accepted architecture, evidence paths, corrections, and decisions remain available for governed reuse after the immediate analysis concludes.

SCALE is not an autonomous architect, a general enterprise AI assistant, an enterprise search rebrand, or a substitute for business architecture governance. AI is the mechanism that accelerates the work, not the source of enterprise truth or formal authority.

## 2. Core proposition

Traditional enterprise search finds documents. Retrieval-augmented generation can summarize relevant passages. Neither is sufficient when the question depends on enterprise relationships.

A decision such as “What is exposed if this initiative slips?” requires more than textual similarity. It may require a trace from an initiative to capability changes, value-stream stages, intended outcomes, business objects, policies, systems, measures, owners, and dependent investments. The response must also distinguish approved knowledge from inference, show contradictory records, respect source permissions, and identify the actor who can resolve uncertainty.

The business architect remains the professional center of that work. SCALE accelerates discovery, structure, traversal, comparison, challenge, and work-product development. The BA sets the architecture context, validates meaning, challenges findings, interprets business consequences, and owns the resulting architecture and advice.

### 2.1 Recurring work cycle

SCALE supports five recurring business architecture activities:

1. **Discover:** bring strategies, initiatives, processes, organizational information, existing architecture, requirements, decisions, and other enterprise evidence into the decision context.
2. **Structure:** identify and organize capabilities, value streams, organizations, information, stakeholders, strategies, initiatives, business objects, and typed relationships for business-architect review.
3. **Analyze:** trace impacts, gaps, duplication, dependencies, alignment, capability implications, affected stakeholders, and questions worth investigating.
4. **Create:** turn the analysis into impact assessments, initiative decompositions, capability assessments, alignment views, heatmaps, briefs, and other BA work products.
5. **Maintain:** refine mappings, add evidence, record human disposition, resolve ownership, update status, and carry accepted architecture into later work.

Analyses conclude. Governed architecture accumulates.

### 2.2 Three-layer product model

| Product layer | Purpose | Characteristic contents or actions |
|---|---|---|
| **Architecture Workspace** | Persistent governed business architecture knowledge | Capabilities, value streams, organizations, information, stakeholders, strategies, initiatives, business objects, relationships, evidence, status, ownership, and history |
| **SCALE Agent** | AI-assisted reasoning and evidence work over authorized content | Extract, suggest, compare, trace, challenge, analyze, detect inconsistencies, and summarize with provenance |
| **Business Architecture Workbench** | Practitioner environment in which the BA performs work and composes decision support | Impact, initiative, strategy, capability, modernization, operating-model, stakeholder, information, and work-product analyses |

In the portable distribution, the workspace persists through exported Markdown, JSON, and CSV; the agent behavior is supplied by a controlling instruction file; and the workbench is the approved AI project or conversation in which the architect performs the work. An integrated enterprise implementation may replace those portable components with governed services while preserving the same operating contract.

### 2.3 Decision-led first use

The first interaction begins with “What are you trying to understand?” Appropriate entry paths include assessing an initiative, exploring a strategy, analyzing a change, building architecture, or creating a work product.

The standard path is:

> **Question → Evidence → Architecture → Analysis → Work product**

Validated architecture, evidence, review history, and unresolved questions then enter the continuing maintenance cycle.

### 2.4 Portable distribution model

Version 0.5 packages the operating model into a bring-your-own-AI kit containing:

- controlling SCALE agent instructions;
- a copy-and-paste launch prompt;
- vendor-neutral platform setup guidance;
- the analysis workbook and reference architecture;
- a human-readable workspace export template;
- JSON schema, starter JSON, and CSV interchange registers;
- a fictional Northstar source case and completed SCALE walkthrough;
- version history and integrity hashes.

The kit makes SCALE usable without a hosted application. It does not provide enterprise identity, source-system access control, persistent storage, retrieval infrastructure, repository synchronization, or governed writeback. The user must select an AI environment authorized for the content and preserve exported state in an appropriate governed location.

## 3. Product boundary

### SCALE does

- help the business architect frame a question in its decision context;
- inventory and assemble user-supplied authorized evidence around that question;
- propose architecture concepts and typed relationships for review;
- retrieve governed architecture records and supporting evidence;
- traverse relevant upstream and downstream relationships;
- identify dependencies, overlap, gaps, stale records, and conflicts;
- distinguish fact, inference, assumption, recommendation, and unresolved conflict;
- explain the architecture path followed;
- cite source records and passages;
- identify confidence and the basis for it;
- identify the owner or forum authorized to decide;
- assist development of decision-focused BA work products;
- record acknowledgements, overrides, corrections, exceptions, and outcomes;
- preserve accepted architecture and provenance for governed reuse;
- propose repository changes for normal human review.

### SCALE does not

- infer undocumented enterprise facts from generic model knowledge;
- approve architecture, policy, investment, or operating decisions;
- silently reconcile competing definitions or ownership claims;
- bypass source-system permissions;
- replace architecture, portfolio, policy, records, or risk governance;
- make the language model the system of record;
- treat an AI proposal as approved architecture without human disposition;
- begin with unrestricted document ingestion or an open-ended request to discover what AI can find;
- require every enterprise domain to be complete before use;
- treat response volume or novelty as proof of value.

## 4. Primary user and governed collaborators

| Role | Business architecture task or governed need | Appropriate SCALE interaction |
|---|---|---|
| **Business architect (primary user and operator)** | Frame decision scenarios; traverse strategy, value, capability, information, organization, initiative, policy, and enablement linkages; assess impact, gaps, ownership, and options | Full architecture path, evidence, conflicts, confidence, correction workflow, and decision-support composition |
| Business architecture practice lead or steward | Govern methods, definitions, relationship semantics, quality, review, adoption, and reusable analysis patterns | Stewardship controls, quality views, evaluations, exceptions, and operating measures |
| Business decision owner or executive | Understand consequences, options, tradeoffs, confidence, and accountable action | Concise decision view prepared from the governed architecture, without repository administration detail |
| Portfolio or transformation lead | Assess investment coverage, dependency, sequencing, duplication, and unsupported outcomes | Decision-focused views with drill-down to business architecture evidence |
| Business content owner or subject-matter expert | Validate definitions, ownership, performance, policy, exceptions, and proposed changes | Review, approve, reject, delegate, correct, and record rationale |
| Enterprise, data, product, process, or technology specialist | Contribute and validate enabling dependencies that intersect the business architecture | Contributor views bounded to governed sources, relationships, and review responsibilities |
| Knowledge engineer or repository steward | Maintain identity, schemas, retrieval, technical quality, access, and lifecycle | Administrative controls, evaluations, exceptions, and audit |

### 4.1 Primary-user operating model

SCALE assumes that the business architect leads the interaction from beginning to end. The BA:

1. frames the business decision, audience, scope, time horizon, and value at stake;
2. selects the business architecture domains, relationships, evidence, and existing models needed for the inquiry;
3. reviews proposed concepts and relationships, then accepts, modifies, rejects, or investigates them;
4. curates architecture meaning and source authority with accountable content owners and specialists;
5. inspects evidence paths, challenges inferences, and exposes conflicts or gaps;
6. translates the analysis into consequences, options, dependencies, confidence, and a decision-focused work product;
7. carries accepted architecture, corrections, decisions, and unresolved questions into continuing stewardship.

Other roles may participate in bounded review or consume BA-prepared outputs, but they do not change the design center. SCALE is primarily a tool through which the business architect performs and scales disciplined business architecture analysis.

## 5. Decision contract

Every SCALE interaction follows a decision-led path directed by the business architect.

### 5.1 Question

The business architect identifies:

- the decision or question;
- the decision owner and audience;
- the relevant scenario and time horizon;
- the authorized scope;
- the required evidence;
- what a sufficient answer must contain;
- whether a policy-sensitive or regulated decision requires mandatory review.

### 5.2 Evidence

Assemble only the authorized sources, records, existing architecture, models, decisions, and experienced owners relevant to the question. Record source authority, status, effective date, access, conflict, and limitation.

### 5.3 Architecture

Reuse governed architecture where it is fit for purpose. Propose missing concepts and typed relationships where the analysis requires them. Keep every machine proposal distinct from accepted architecture until the business architect and accountable stewards record a disposition.

### 5.4 Analysis

Select relevant domains, then follow only the typed relationships needed to answer the question. Apply direction, status, date, scenario, confidence, and access filters. Do not retrieve an unrestricted neighborhood merely because elements are connected.

Trace impact, dependency, overlap, alignment, ownership, conflict, gaps, and uncertainty. Distinguish fact, inference, assumption, recommendation, and unresolved conflict.

### 5.5 Work product

Prepare the smallest useful decision view with:

- a direct response;
- the relationship path followed;
- supporting records and source passages;
- material conflicts, missing knowledge, and stale content;
- confidence and its basis;
- remaining judgment;
- the accountable owner or forum;
- the next governed action.

### 5.6 Continue

Record human acknowledgement, acceptance, modification, rejection, investigation, correction, override, exception, escalation, or decision. Proposed changes to governed knowledge follow normal stewardship, review, versioning, and access controls. Accepted architecture receives an owner, effective dates, review triggers, and a reuse or retirement path.

## 6. Logical reference architecture

The portable kit operationalizes the decision contract through instructions and exported files. It does not instantiate all eight enterprise layers below. These layers describe a more integrated implementation when the organization requires automated retrieval, identity, permissions, durable repositories, workflow, or audit.

### Layer 1: Governed sources

Possible sources include:

- architecture platforms;
- portfolio and product systems;
- strategy and performance repositories;
- policy, risk, control, and decision records;
- data catalogs and application inventories;
- approved documents and collaboration repositories;
- operational references required to interpret current state.

Each source retains an identifiable authority, owner, permission model, effective date, and retention basis.

### Layer 2: Normalization and identity

This layer resolves:

- stable identifiers;
- canonical names and definitions;
- element types and levels;
- accepted aliases;
- duplicates and specializations;
- current, proposed, historical, and retired status;
- effective and review dates;
- content owners and stewards;
- authority and confidence;
- source provenance;
- access classification.

The purpose is not to erase legitimate local variation. It is to make shared meaning and variation conditions explicit.

### Layer 3: Architecture knowledge graph

A property graph represents durable typed relationships. It is optimized for traversal and impact reasoning rather than document storage.

The graph supports questions such as:

- Which capabilities enable this value-stream stage?
- Which objectives depend on those capabilities?
- Which initiatives change them?
- Which business objects, policies, organizations, and systems are involved?
- Which decisions or risks constrain the path?
- Where do two initiatives overlap?
- Which records conflict or lack an owner?

### Layer 4: Evidence index

A document store preserves approved source material. A vector index supports semantic discovery of candidate passages and records.

The vector index is not the authority for enterprise facts. Similarity can locate evidence, but it cannot establish identity, status, ownership, approval, or the validity of a relationship.

### Layer 5: Question-aware orchestration

The orchestration layer:

1. classifies the question and decision scenario;
2. resolves user identity and permissions;
3. selects the relevant architecture domains;
4. chooses traversal patterns and depth limits;
5. retrieves graph records and source evidence;
6. checks status, dates, confidence, and conflicts;
7. constructs an evidence package;
8. instructs the model to answer within the contract;
9. validates citations and unsupported claims;
10. routes policy-sensitive output to required review.

### Layer 6: Architecture reasoning

The SCALE Agent assists with bounded reasoning over the evidence package and governed architecture. It may:

- extract candidate concepts from authorized evidence;
- propose definitions and typed relationships;
- compare records, scenarios, and architecture paths;
- trace impact, dependency, overlap, and alignment;
- identify inconsistencies, gaps, stale content, and unsupported claims;
- summarize findings with evidence, classification, and confidence.

Every material proposal remains identifiable as a proposal until a named human disposition is recorded.

### Layer 7: Business Architecture Workbench

The workbench organizes the interaction around BA analyses and work products rather than generic prompts. It allows the business architect to inspect:

- the business question, audience, scope, and sufficiency criteria;
- architecture elements and typed relationship paths;
- source records and passages;
- dates, status, owners, access, and confidence;
- conflicts, gaps, alternate scenarios, and prior decisions;
- proposed concepts, relationships, corrections, and follow-up actions;
- architect dispositions and rationale;
- the decision-focused work product being composed.

### Layer 8: Workflow, identity, and governance

Security, review, and institutional memory apply end to end. The layer records and enforces:

- authorized purpose, identity, role, and source permissions;
- records, relationships, and evidence retrieved;
- generated proposals, findings, model/version context, and confidence;
- human acceptance, modification, rejection, investigation, correction, override, and rationale;
- decisions, exceptions, expiry dates, evaluations, and incidents;
- retention, redaction, legal hold, export, and access rules;
- stewardship, review triggers, effective dates, reuse, and retirement.

This layer prevents the language model from becoming a record authority and prevents accepted architecture from losing its governance after the immediate analysis.

## 7. Data-store responsibilities

| Component | Responsibility | Must not become |
|---|---|---|
| Governed source system | Authority for specialist records and approved source material | A source that SCALE silently overwrites |
| Property graph | Canonical architecture identity and typed relationship traversal | A dump of every document, task, or operational transaction |
| Document store | Preserved approved sources and retrievable passages | An unclassified collection with unclear authority |
| Vector index | Semantic discovery and evidence candidate ranking | The system of record for definitions or relationships |
| Relational workflow store | Reviews, audit, overrides, exceptions, evaluations, and dispositions | A parallel architecture repository |
| Orchestration service | Permission-aware retrieval, traversal, evidence assembly, and answer control | An autonomous decision authority |
| Language model | Explanation, synthesis, classification, and bounded inference | A memory of unrestricted enterprise truth |

## 8. Canonical knowledge model

### 8.1 Intent and value

- Driver
- Assessment
- Objective
- Outcome
- Stakeholder
- Value proposition
- Product or service
- Metric or measure
- Risk

### 8.2 Operating architecture

- Capability and capability level
- Value stream and stage
- Business object and lifecycle state
- Process, when sequence and control are relevant
- Policy and business rule
- Organization unit and actor
- Role and decision right

### 8.3 Change and enablement

- Initiative, epic, or work package
- Requirement
- Architecture decision
- Current-state condition
- Target-state condition
- Transition dependency
- Application or system
- Integration
- Technology reference

### 8.4 Evidence and governance

- Source artifact
- Evidence passage
- Definition
- Owner and steward
- Status
- Version
- Effective period
- Confidence
- Access classification
- Review
- Exception
- Override
- Change record

## 9. Minimum schemas

### 9.1 Element record

```yaml
id: CAP-00127
type: capability
name: Shipment Information Management
definition: The ability to establish, maintain, govern, and provide shipment information throughout its business lifecycle.
level: L2
status: approved
owner: ROLE-0042
steward: PERSON-RESTRICTED
source_ids:
  - SRC-0088
effective_from: 2026-07-01
review_by: 2027-01-01
confidence: high
confidence_basis: Approved by the capability owner and used in two active portfolio decisions.
access_classification: internal
version: 3
```

### 9.2 Relationship record

```yaml
id: REL-09441
type: enables
source_id: CAP-00127
target_id: VSTAGE-0024
scenario_id: SCENARIO-BASELINE
status: approved
evidence_ids:
  - E-088
owner: ROLE-0042
effective_from: 2026-07-01
review_by: 2027-01-01
confidence: high
access_classification: internal
version: 2
```

In this illustrative record, `E-088` identifies a governed evidence record whose source locator is `SRC-0088-P14`. Keep that locator in the evidence register; `evidence_ids` links to the evidence record, not directly to a source passage.

### 9.3 Required metadata

Every governed element and relationship should have, where applicable:

- stable identifier;
- type and subtype;
- name and definition;
- level or granularity;
- status;
- owner or steward;
- source and source location;
- effective date and review date;
- scenario or scope qualifier;
- confidence and confidence basis;
- access classification;
- version and change record.

## 10. Minimum relationship vocabulary

| Source | Relationship | Target | Example question supported |
|---|---|---|---|
| Driver | influences | Objective | Why does this objective exist? |
| Objective | seeks | Outcome | What observable result defines success? |
| Stakeholder | receives | Value proposition | Who receives the value? |
| Value stream | serves | Stakeholder | Which value delivery path is affected? |
| Capability | enables | Value-stream stage | Which abilities make the stage possible? |
| Capability | governs or uses | Business object | Which abilities change or depend on this information? |
| Organization | performs | Capability | Who currently performs the ability? |
| Role or forum | decides | Architecture element or change | Who can authorize the decision? |
| Initiative | changes | Capability | Which investment is changing the ability? |
| Initiative | affects | Value-stream stage | Where does the initiative change value delivery? |
| Initiative | depends on | Initiative or condition | What must occur first? |
| Measure | evaluates | Outcome, capability, or stage | How is performance known? |
| Policy | constrains | Capability, stage, or initiative | Which directive limits the option? |
| Risk | threatens | Outcome or capability | What exposure could prevent value? |
| Application | enables | Capability | Which technology currently supports the ability? |
| Decision | approves, rejects, or conditions | Proposed change | What was decided and under what conditions? |
| Source | supports | Element or relationship | What evidence makes this claim authoritative? |

Organizations should extend the vocabulary only when a recurring question requires a distinct semantic relationship and stewardship exists to maintain it.

## 11. Temporal and epistemic status

SCALE should never collapse time or certainty.

### Recommended lifecycle states

- observed;
- proposed;
- under review;
- approved;
- active;
- superseded;
- retired;
- rejected;
- historical.

### Recommended response classifications

- **Fact:** Supported by a current governed record or approved source.
- **Inference:** Derived from facts and typed relationships; the reasoning path is shown.
- **Assumption:** Used for a scenario but not established as enterprise truth.
- **Recommendation:** A proposed judgment based on stated criteria and evidence.
- **Conflict:** Two or more material sources or records cannot be reconciled automatically.
- **Unknown:** Required information is absent, inaccessible, stale beyond tolerance, or unowned.

## 12. Answer contract

Every material response should contain:

1. **Decision context**: the question, scope, scenario, time horizon, audience, and decision owner.
2. **Direct answer**: a concise response before detail.
3. **Architecture path**: the typed relationships traversed.
4. **Evidence**: governed records and source citations for material factual claims.
5. **Classification**: fact, inference, assumption, recommendation, conflict, or unknown.
6. **Confidence**: a visible assessment and basis.
7. **Conflicts and gaps**: contradictory, stale, missing, inaccessible, or unowned knowledge.
8. **Options and consequences**: where the decision requires alternatives.
9. **Decision and owner**: the remaining human judgment and authorized actor or forum.
10. **Next action**: review, correction, escalation, acknowledgement, or decision record.

## 13. Confidence model

Confidence should not be generated as an unexplained percentage. It should be based on visible dimensions.

| Dimension | Questions |
|---|---|
| Authority | Is the source approved, official, and owned? |
| Freshness | Is the record effective for the decision horizon and within review tolerance? |
| Agreement | Do relevant sources and records agree? |
| Completeness | Are the required domains, relationships, and owners present? |
| Directness | Is the claim directly supported or inferred through several links? |
| Retrieval quality | Were the expected records and passages found within the requesting business architect’s and authorized collaborators’ permissions? |

The response should state which dimensions lower confidence and what action could improve it.

## 14. Governance model

The default version 0.5 operating rule is **propose, disclose, review, and record**.

- The business architect frames the inquiry, reviews the evidence path, interprets the result, and prepares decision support.
- SCALE retrieves, traverses, explains, and recommends within the governed scope.
- Authorized collaborators may acknowledge, challenge, or propose corrections within their defined authority.
- Business architecture stewards and content owners approve repository changes.
- Accountable business authorities make business decisions.
- Policy-sensitive outputs enter mandatory review.
- Every material override or exception records rationale, owner, date, and expiry or review trigger.

### 14.1 Roles

| Role | Accountability |
|---|---|
| **Business architect (primary user)** | Frames decision scenarios, determines the relevant architecture scope, curates linkages, evaluates evidence and inference, prepares decision support, and routes corrections |
| Business decision owner | Owns the decision, value, and consequences |
| Business architecture content owner | Owns the business meaning and formal disposition of governed content |
| Business architecture steward | Maintains definitions, relationship semantics, quality, status, review, and reusable analysis patterns |
| SCALE product owner | Owns use cases, service levels, adoption, backlog, value, and operating funding; normally sits with or is accountable to the business architecture practice |
| Knowledge engineer | Maintains schemas, identity, graph, retrieval, evaluation, and technical quality |
| Risk and security authority | Sets access, model use, logging, retention, review, and incident controls |
| Platform owner | Operates infrastructure, reliability, integration, and support |
| Authorized collaborator | Reviews or consumes a bounded BA-led output, discloses corrections, and records material disposition within assigned authority |

### 14.2 Write patterns

SCALE is read-oriented by default.

Allowed without content approval:

- search;
- retrieval;
- traversal;
- explanation;
- quality flags;
- acknowledgement;
- correction proposal;
- override or exception request.

Requires normal human approval:

- new canonical element;
- changed definition;
- new or changed governed relationship;
- owner or steward change;
- lifecycle-state change;
- access-classification change;
- approved target-state or decision record.

## 15. Security, privacy, and records controls

- Preserve source permissions during indexing and retrieval.
- Test access at the record, relationship, passage, answer, citation, and export levels.
- Prevent inferred relationships from revealing restricted facts.
- Treat prompts, retrieved context, outputs, corrections, and logs according to classification.
- Define approved model hosting and data-use terms before ingestion.
- Minimize personal data and avoid exposing named individuals when a role identifier is sufficient.
- Define retention, legal hold, deletion, and records schedules.
- Log privileged operations and policy-sensitive questions.
- Provide incident response for leakage, unsupported claims, harmful recommendations, and corrupted source data.
- Re-evaluate controls when adding writeback, external models, new domains, or broader audiences.

## 16. First analysis

A bounded first analysis is an adoption path, not a temporary product identity. It should produce a useful BA work product while establishing architecture, evidence, governance, and stewardship that can continue.

### 16.1 Start narrow enough to govern

Include:

- one business question and accountable decision owner;
- one named business architect responsible for the analysis and resulting architecture;
- the architecture domains and typed relationships needed for that question;
- authorized evidence with identifiable source authority;
- known questions, expected paths, and sufficiency criteria;
- human review and disposition for material proposals;
- role-based access and permission-aware inference;
- correction, override, exception, and escalation routes;
- named stewardship, review triggers, and a reuse or retirement path.

### 16.2 Explicit exclusions

- enterprise-wide ingestion before a question requires the scope;
- a general document-search deployment;
- an open-ended model exercise measured by response volume or novelty;
- autonomous architecture, policy, investment, or operating decisions;
- unreviewed repository writeback;
- unrestricted model training on enterprise content;
- replacement of architecture, portfolio, policy, records, or risk governance.

## 17. First-analysis sequence

### 17.1 Establish the business question

- name the lead business architect;
- identify the decision owner, audience, and decision point;
- define scope, time horizon, value at stake, and sufficiency criteria;
- choose the required work product;
- define access, review, and stop conditions.

**Review point:** The business architect can state how the work will support a named decision, and the decision owner can state what a useful answer must enable.

### 17.2 Connect the evidence boundary

- identify existing architecture and source records;
- classify source authority and access;
- preserve effective dates, status, ownership, and known limitations;
- exclude evidence that is unnecessary, unauthorized, or ungovernable.

**Review point:** Every material source has an identifiable authority, purpose, permission basis, and relationship to the question.

### 17.3 Develop the relevant baseline

- normalize identifiers and definitions;
- reuse fit-for-purpose architecture;
- propose missing elements and relationships;
- link supporting evidence;
- expose gaps, conflicts, and stale records;
- record human acceptance, modification, rejection, or investigation.

**Review point:** The selected questions have maintainable architecture paths or explicit gaps, and machine proposals remain distinguishable from governed knowledge.

### 17.4 Perform the analysis and create the work product

- traverse the relevant architecture paths;
- compare scenarios and test assumptions;
- classify findings and confidence;
- inspect permissions, evidence, and unsupported claims;
- document implications, options, owners, and the next governed action;
- compose the work product required by the audience.

**Review point:** The business architect can explain every material finding, its provenance, its uncertainty, and the judgment still required.

### 17.5 Carry accepted knowledge forward

- retain validated elements, relationships, evidence, and dispositions;
- assign stewards and review triggers;
- record decisions, rejected options, corrections, exceptions, and rationale;
- identify adjacent questions that can reuse the architecture;
- retire or supersede knowledge that should not remain current.

**Review point:** Continuing architecture has named stewardship, intact provenance, permission controls, and a credible maintenance path.

## 18. Operating measures

Targets should be set locally and reviewed as part of the operating model. Usage is a supporting signal, not proof of decision value or architecture quality.

| Measure | Minimum intent |
|---|---|
| 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 and actionable |
| Access-control fidelity | No answer, citation, relationship, or export exceeds source permissions |
| Decision effort | Measured reduction in the effort required to assemble and explain governed evidence |
| Correction closure | Material corrections have an owner, disposition, and turnaround target |
| Architecture reuse | Accepted knowledge supports additional questions without losing context or provenance |
| Decision support | Named decisions are improved, accelerated, reframed, or stopped |
| Maintenance burden | Content stewardship and platform support are sustainable within named capacity |

## 19. Common failure modes

### Fluent search wrapper

The system summarizes documents but cannot follow governed relationships or distinguish authority from textual similarity.

### Enterprise-first scope

The team attempts to ingest the enterprise before one decision question requires the scope and the organization can govern it.

### Document-first entry

The interaction begins with files and prompts instead of a business question, decision context, or architecture purpose.

### Repository laundering

Stale ownership, ambiguous definitions, and missing provenance acquire false credibility because an AI interface presents them fluently.

### Permission collapse

The answer or citation reveals information the user could not access in the source, or an inferred relationship exposes a restricted fact.

### AI ownership theater

The organization treats the engine as the owner of knowledge or the decision, allowing accountable roles to avoid formal judgment.

### Invisible override

Business architects, reviewers, or decision owners disregard, edit, or act against an answer without recording rationale, preventing institutional learning.

### Automation as the outcome

The service reports prompts, responses, users, or model novelty instead of traceability, reuse, correction closure, effort, and decisions improved.

### Architecture without stewardship

New concepts and relationships accumulate faster than named owners can validate, maintain, retire, or correct them.

### Governance without capacity

The design names owners and review cycles that no funded role can maintain.

## 20. Implementation patterns

### Portable agent kit

Load the SCALE instructions, workbook, reference architecture, and schemas into an approved AI project, custom agent, or bounded conversation. Supply only authorized evidence needed for the question. Export the workspace as Markdown and JSON so accepted architecture, decisions, and open items persist outside conversational memory.

This is the production version 0.5 distribution. It provides disciplined behavior and portable state, but it does not supply enterprise access control, repository synchronization, or automated governance enforcement.

### Microsoft ecosystem

Use structured SharePoint or Dataverse content, Microsoft Graph, enterprise identity and permissions, Copilot Studio or equivalent orchestration, and governed actions. Avoid treating unstructured SharePoint search as the architecture graph.

### EA platform extension

Use the architecture platform as the governed source for elements and relationships. Add evidence retrieval, question orchestration, explanation, workflow, and audit through supported APIs or exports. Do not duplicate repository content without a synchronization and authority rule.

### Graph-native stack

Use a property graph for architecture identity and relationships, a document store and vector index for evidence, a relational store for workflow and audit, and a model-agnostic orchestration layer.

### Lightweight workspace

Use governed Markdown or JSON, stable identifiers, explicit relationship files, source links, access controls, review status, and a focused retrieval service. This is appropriate when a small practice needs to establish the operating model and architecture discipline before buying enterprise tooling.

The platform is secondary. Identity, relationships, evidence, ownership, access, and governance determine trust.

## 21. Evolution path

Add scope only when a recurring decision requires it and stewardship can sustain it.

Possible later capabilities include:

- broader multi-value-stream traversal;
- initiative and system redundancy detection;
- controlled scenario simulation and blast-radius comparison;
- capability heat maps with source evidence and confidence;
- automated quality rules for duplicates, orphans, stale records, and broken relationships;
- integration with architecture, portfolio, policy, data, and product platforms;
- reusable retrieval and answer patterns by decision type;
- structured human-override learning without silent model retraining;
- approved writeback for low-risk metadata under formal controls.

Continue to exclude autonomous enterprise decisions unless the organization deliberately establishes a different authority, risk, and control model.

## 22. Continue, extend, redesign, or retire

### Continue within the current scope when

- the workspace improves named decisions or recurring BA work;
- traceability and access controls meet the operating expectations;
- content owners maintain the governed architecture;
- corrections close within an acceptable period;
- reuse justifies the continuing stewardship burden;
- operating ownership, funding, and support remain explicit.

### Extend when

- demand exists for adjacent decision scenarios;
- the existing architecture and evidence can be reused without losing context;
- new scope has named ownership and a credible maintenance path;
- expansion can preserve the same governance discipline.

### Redesign when

- the questions are valuable but the knowledge model, source authority, permissions, or workflow cannot support them reliably;
- the first analysis reveals a better bounded question or entry path;
- the maintenance burden is concentrated in the wrong system or role;
- the answer contract is too broad or too technical for the business architect and intended decision audience.

### Retire when

- ordinary search answers the questions adequately;
- no accountable owner will maintain the content;
- unsupported claims or access failures remain unresolved;
- the workspace cannot improve a named decision or recurring BA task;
- institutional incentives reward ambiguity or prevent correction;
- continuing cost exceeds demonstrated decision and reuse value.

## 23. Example acceptance questions

1. Which capabilities must improve to achieve Objective O-17, and what evidence supports the current gaps?
2. Which initiatives change those capabilities, and where is there overlap or an unfunded gap?
3. If Initiative I-04 slips by one quarter, which outcomes, value stages, dependencies, and owners are exposed?
4. Which business objects change state in the affected value stage, and which capability governs each change?
5. Who can approve the proposed capability standard, and which business units may vary locally?
6. Which policies or risks constrain the preferred option?
7. What prior decision addressed a similar scenario, and under what conditions does its rationale remain applicable?
8. Which architecture records are stale, contradictory, unowned, or unsupported within this answer path?
9. Which systems enable the affected capabilities, and which linkages are directly evidenced versus inferred?
10. What information is missing or inaccessible, and which owner can resolve it?

## 24. Version history

- **Version 0.3:** Bounded, BA-led pilot reference design with explicit exclusions, governance gates, and scale, redesign, or stop conditions.
- **Version 0.4:** Continuous, architect-led architecture work organized around Discover, Structure, Analyze, Create, and Maintain, with explicit product layers, provenance, and human disposition.
- **Version 0.5:** Portable bring-your-own-AI agent kit with controlling instructions, launch workflow, schemas, exports, and a completed worked example.

## 25. Final design rule

SCALE is ready to continue only when the business architecture practice can govern the knowledge, the business architect can explain the finding and preserve its evidence path, accountable owners can record human judgment, and the organization can stop the system from pretending to know more than the enterprise has established.

The durable outcome is not an impressive AI response. It is a business architect helping the organization make better decisions with less ambiguity while leaving behind architecture, evidence, and institutional memory that can support the next question.