SCALE · Advanced resources
Keep the evidence inspectable.
Useful architecture survives a second question, a skeptical reviewer, and a change in the evidence. These records support that continuity. Enterprise integration would require additional work and accountable operating capacity.
SCALE abbreviates Strategic Capabilities Architecture Linkage Engine. In v0.6.1 it is delivered as instructions, working files, and validation tools for your chosen AI environment.
Implementation boundary
What the portable kit provides.
Use the kit to structure an analysis, inspect its reasoning, and preserve explicit state. Graph storage, synchronized repositories, permission-aware retrieval, and authenticated approval workflows remain possible integrations; the kit does not implement those services.
| Responsibility | Portable practice | Possible integration |
|---|---|---|
| Source authority | Named sources, exact locations, dates, and limitations. | Repositories and connectors that preserve source permissions. |
| Architecture identity | Stable identifiers and explicit typed relationships. | A governed architecture repository or graph. |
| Review | Recorded reviewer, disposition, date, and rationale. | Authenticated review and auditable approval workflow. |
| Continuity | Explicit JSON state and generated readable views. | Versioned storage, access, retention, and recovery controls. |
| Maintenance | Named stewardship, unresolved questions, review triggers. | Funded ownership, review capacity, and service expectations. |
Preserve what a reviewer needs.
Source authority belongs to a particular claim
A capability map can establish agreed terminology without establishing operating performance. A vendor demonstration can establish demonstrated behavior without establishing realized business value.
Keep the exact source location, applicable scope, date, and limitations. Distinguish direct support from inference and assumption. Preserve conflicts and identify what could resolve them. Neither a newer document nor an approved but outdated model should silently settle the dispute.
Relationships need an explicit meaning
A capability may enable a value-stream stage; an application may support a capability. Those are separate assertions with separate evidence. Keep each relationship atomic: one source element, one type, and one target element.
Preserve current and proposed status. Stable identifiers prevent a renamed concept from becoming an apparent duplicate. A plausible path identifies where to investigate; it does not establish causal effect, economic value, or operating readiness.
Review what can change the decision
Prioritize causal claims, conflicting evidence, disputed ownership, consequential relationship changes, and assumptions carrying the recommendation. Record acceptance, modification, rejection, or investigation with a reason.
Keep rejected interpretations when they explain a correction. Review dependent claims when a source changes. A reviewer name written in a file records supplied information; it is not authenticated proof of approval.
Optional structured workspace
Export, validate, and resume structured records.
A reviewed brief and continuation note are the default way to carry a small analysis forward. Choose this structured workflow when you need machine-readable relationships, formal record checks, or a repository handoff. The separate continuity bundle supplies its instructions, schemas, and optional Node.js tools without Northstar evidence or answers.
In the structured workflow, the JSON workspace is the explicit handoff. Its readable view helps people inspect it. Keep the two together and regenerate the view after changing the structured state, so two independently edited versions do not drift apart.
- Export. Preserve the question, evidence, relationships, proposals, findings, decisions, and open conditions. Keep rejected claims and their reasons.
- Validate. Use the included tools to check the required structure and record references. Inspect whether the cited sources actually support the important claims.
- Resume. Load the state in a fresh conversation. Ask about a corrected finding and an unresolved condition; verify their source, review status, and scope.
Set up, export, and resume a structured workspace
Optional structured continuity
Release 0.6.1 · Workspace schema family 0.6
Choose structured continuity when a longer or shared analysis needs explicit records, stable identifiers, review history and checks between exports. A short brief and readable continuation note remain the ordinary workflow.
Get the files
Download https://stephenklahr.com/downloads/scale-structured-continuity-v0.6.1.zip and extract it. This bundle contains the structured instructions, schemas and tools without Northstar evidence or answers.
Keep SCALE-AGENT-INSTRUCTIONS.md available. For the assistant's structured work, attach this document and:
- schemas/scale-workspace.schema.json;
- schemas/relationship-vocabulary.json;
- schemas/scale-workspace-starter.json for a new record, or your current workspace JSON;
- the relevant source evidence.
If the assistant will run validation, also make the tools folder available in its code environment. Confirm which files and execution tools it can access. Reading a schema is not the same as running validation.
A continuation note may help reconstruct a draft, but it cannot prove missing review history or recreate source evidence. Retain gaps and have the architect check the result.
Structured working rules
JSON is the canonical state. Preserve existing identifiers, evidence and claim locators, scope, dates, confidence basis, review status, decisions, unresolved items and history. Keep facts, inferences, assumptions, recommendations, conflicts and unknowns distinct. For confidence use high, medium, low or insufficient, with a specific basis.
Each architecture relationship has one source element, one allowed relationship type and one target. Record a recommendation as an analysis or proposal, not a graph edge. Use only the records needed for the question.
Present material proposed changes in coherent groups for human review. Record a reviewer's identity, actual disposition, time and rationale only when known. An accepted record requires the corresponding completed review. Modify and Investigate leave a record proposed until its corrected version is accepted. An analysis review does not establish a business owner's approval.
Preserve rejected interpretations and their reasons. Keep prior exports unchanged. Continued exports retain earlier records, record corrections and supersession, and identify their prior export. Use the schema's unknown values and document limitations; never invent dates, source locations or approvals. For undated sources, follow schemas/README.md to distinguish receipt time from the unknown period a source describes.
Export your work
Ask: EXPORT WORKSPACE. Produce my complete JSON workspace using the attached schema. Preserve corrections and rejected claims. Validate this file if you can run the supplied tools, report the command and result, and generate its readable view. Otherwise label it unvalidated.
Save the resulting JSON under a distinct name, such as my-analysis-01.workspace.json. Keep it in your approved working folder alongside the relevant evidence. A displayed JSON block must be saved as a .json file before a local validator can read it.
For local validation, use Node.js 24 or later. Open a terminal in the extracted bundle's tools folder and install its dependencies once:
npm install
Save your JSON in the extracted bundle's root folder. From tools, validate your actual file:
node validate-scale.mjs --kit .. --file ../my-analysis-01.workspace.json
After it passes, generate the readable view:
node render-scale-workspace.mjs --file ../my-analysis-01.workspace.json --output ../rendered
Read the generated Markdown in rendered. The generated CSVs are partial views, not backups. Fix canonical JSON and regenerate views when needed. Follow tools/README.md for troubleshooting; a command that tests bundled fixtures is not validation of your own export.
Validation checks structure and record integrity. You must still check important source claims and human decisions. If tools cannot run, keep the export labeled unvalidated; do not describe an assistant's inspection as a successful validator run.
Resume structured work
Attach the instructions, this document, schema/vocabulary, latest JSON and required evidence. Ask: CONTINUE ANALYSIS. Confirm the workspace identity, scope, evidence cutoff, rejected claims, decisions and reviews due. Identify what evidence you can access before adding new findings.
Save the next export as my-analysis-02.workspace.json and keep the first. From the tools folder, check it against the earlier file:
node validate-scale.mjs --kit .. --file ../my-analysis-02.workspace.json --previous ../my-analysis-01.workspace.json
Then generate its view using the same renderer command with the new filename. Keep both exports. Do not claim a continuity check passed unless the validator was run with the prior file.
Use MIGRATION.md for older workspace versions. The documentation release is 0.6.1; the JSON scaleVersion remains "0.6".
Validation commands and tool troubleshooting
Optional workspace tools
Patch 0.6.1 · JSON schema family 0.6
These tools are for checking and rendering a saved JSON workspace. You can use SCALE's normal conversation and Markdown workflow without installing them.
JSON is the canonical state. The renderer creates a complete Markdown view and six partial CSV views. CSV files are not a complete workspace backup.
Install once
Use Node.js 24, the major version used by the site build. From the unpacked continuity bundle or full reference kit:
cd tools
npm install
cd ..
The validator uses the supplied Ajv and date-format dependencies. The renderer uses Node's standard library. Commands below run from the folder containing tools/ and schemas/; quote paths containing spaces.
Check your own file
node tools/validate-scale.mjs --kit . --file my-workspace.json
To check a continuation against its saved prior export:
node tools/validate-scale.mjs --kit . --file next-workspace.json --previous my-workspace.json
The second command checks both files and verifies continuity: identity, preserved prior records, recorded changes and retained history. A successful result checks structure and declared controls. It does not establish whether claims are true or approvals authentic.
These commands work in the continuity bundle without Northstar examples or fixtures. You do not need to download the full reference kit.
Render a validated file
node tools/render-scale-workspace.mjs --file next-workspace.json --output rendered
This writes a Markdown file and a CSV folder under rendered/. It leaves the input JSON unchanged. If --output is omitted, it uses a rendered/ folder next to the input. Regenerate the views after editing JSON.
node tools/validate-scale.mjs --help
node tools/render-scale-workspace.mjs --help
Unknown dates
Use explicit nulls and recorded limitations instead of invented source dates. A documented receipt can establish possession by a cutoff, but cannot establish the source's effective period. Undated context needs a specific qualification at each citation. See ../schemas/README.md for the fields and limits.
Check the reference installation
The following mode is only for the full reference kit or site repository:
node tools/validate-scale.mjs --kit . --test
It validates the shipped starter, Northstar A/B/C answer snapshots, continuity and failure fixtures. It does not test your own export. The smaller continuity bundle deliberately omits answer snapshots and fixtures, so this mode is unavailable there. Use the --file commands above.
In the site repository, use scripts/ instead of tools/; the default command locates the repository's kit directory.
Schema validation establishes record structure. Additional checks can detect broken references. Neither establishes sound business judgment or proves a human approval occurred.
v0.6 changes the workspace contract. Keep a copy of existing v0.5 work and follow the migration guidance; do not silently relabel an old export.
Read the migration guidance
Continue earlier SCALE work
Release 0.6.1 · Workspace schema family 0.6
Ordinary notes and briefs
A readable continuation note does not need schema migration. Keep the earlier note, attach it with the current instructions and required evidence, and use CONTINUE-PROMPT.md. Check its scope, corrections and source access before continuing.
A note is not a structured workspace. Moving a note into structured continuity creates a draft for review; it does not recover approval history or evidence that the note never preserved.
Structured workspaces from v0.6
Release 0.6.1 simplifies the default workflow and documents structured continuity as an explicit option. It keeps the v0.6 download paths and JSON schema family. Do not change scaleVersion from "0.6" to "0.6.1".
Keep the original JSON. Use the current structured continuity bundle to validate it before relying on it as a handoff. Do not convert a structured workspace to a note and discard the canonical record.
Structured workspaces from v0.5
v0.6 changed the state contract. Keep the original v0.5 export unchanged as evidence of what was recorded.
- Create a named v0.6 draft and record the original export's identity and the migration.
- Preserve existing evidence and architecture IDs. Carry source locators, dates, scope and confidence basis from actual records; retain unknowns and limitations.
- Split compound relationship rows into atomic typed relationships. Move recommendations to analyses/proposals.
- Carry rejected and superseded records, decisions, conditions and unresolved items forward.
- Record review identities and dates only when supported. Missing review metadata remains unresolved; migration never invents approval.
- Validate the new JSON and generate its readable view. Compare it with the original before accepting the migration.
There is no automatic lossless v0.5 migration. Missing provenance and review history require human resolution. CSV extracts alone cannot reconstruct a complete workspace.
Recorded evaluation
Show the result, including its limits.
Northstar’s authored teaching examples explain the method. The following recorded comparison examines two responses to one evidence packet. It provides a small observation to inspect, not a broad claim about model accuracy, practitioner productivity, or enterprise value.
What the first comparison showed
30 September 2026 · One matched pair · Northstar Episode A
Both assistants produced a defensible next-step recommendation. This exercise did not establish a SCALE advantage. Both proposed the five-day diagnostic capped at $15,000, preserved uncertainty, compared the narrow alternative and deferred unsupported procurement.
Two independent assistant contexts received the same bounded packet and decision request. One additionally received the SCALE v0.6 working instructions. Neither received instructor answers or later evidence. The protocol was defined before the outputs. Complete captured outputs are available for general analysis and SCALE.
Review against the predeclared criteria
Review was performed by the implementation assistant, unblinded. It was not a review by Stephen or an independent human evaluator.
| Criterion | General assistant | SCALE assistant | Evidence in the captured outputs |
|---|---|---|---|
| Evidence versus hypothesis and disputed definitions | Observed | Observed | General: “This is not a comparable pilot baseline.” SCALE: “Neither figure supplies a reconciled baseline or attributable savings.” |
| Allocation/estimate versus confirmed reservation | Observed | Observed | General distinguishes allocation from physical reservation and expiry. SCALE calls for reservation identity, state and expiry. |
| Narrow alternative and cost of delay | Observed | Observed | Both compare A4 and qualify the $27–54k gross delay scenario. |
| Learning spend, cheaper test and changed action | Observed | Observed | Both select the $15k diagnostic and specify the circumstances favoring A0, A1, A4 or stopping. |
| Customer-value balancing measures | Observed | Observed | Both retain original/revised commitments and restoration time; SCALE also explicitly names lost/deferred demand. |
| Evidence cutoff and no premature realized-benefit claim | Observed | Observed | Both bound the recommendation to January 9 and reject inference of platform value or enterprise repeatability. |
| Authority, conditions, capacity and stopping | Observed | Observed | Both preserve Council authority and condition further commitment on readiness/capacity evidence. |
| Complete recommendation and inspectable references | Observed | Observed | Both supply an actionable brief and E-* references. SCALE more often cites numbered sublocators and states confidence explicitly. |
No material unsupported source claim was identified in this limited review. That is a review finding, not a guarantee of factual completeness. No response was used as an enterprise approval.
What this does and does not establish
The packet is highly guided: it explicitly names several analytical traps and proposes a cheap diagnostic. A capable general assistant can follow it well. One pair cannot separate prompt effects from model variation or generalize across models, users or organizations.
No human review time, total task effort, productivity gain, organizational outcome or monetary benefit was measured. Model/version and generation settings were not exposed by the harness. The output-length target was approximate, not a controlled token budget.
The website's teaching drafts and completed workspace snapshots are authored examples. They are distinct from these observed runs. Structural schema/semantic/continuation tests demonstrate specific file behavior; they do not prove better professional judgment.
Next useful evaluation
Use less-leading, independently prepared evidence; repeat matched conditions; randomize output labels; involve independent reviewers; and measure total analysis plus review time, material unsupported claims, missed conflicts and reuse on a second question. Keep the result public even if the generic condition performs equally well.
Optional future design
Earn the case for integration.
I would begin with one recurring question, the sources needed to answer it, and reviewers able to inspect the result. Infrastructure becomes worth considering when bounded use demonstrates value and the maintenance work is sustainable.
Count source maintenance, review, correction, and operating cost alongside any time saved making a draft. Assign source ownership, architecture stewardship, review, decision authority, and service operation through existing governance wherever possible.
Retire or redesign an integration if sources cannot remain current, reviewers lack capacity, permissions cannot be preserved, or a simpler workflow answers the question at lower total cost.
Read the optional enterprise design
Extending SCALE in an organization
Version 0.6 · Optional reference design
The portable kit works over supplied files and explicit saved state. It does not run a graph database, synchronize an EA platform, enforce enterprise permissions or operate a hosted service.
Consider integration only after bounded analyses show useful results and the review/maintenance work is sustainable. Choose a specific recurring question, a source owner, an accepted relationship model and a measurable service expectation before choosing infrastructure.
Responsibilities
| Responsibility | Portable practice today | Possible integrated implementation |
|---|---|---|
| Source authority | Named sources, dated evidence, exact locators and recorded limitations | Permission-aware connectors to governed repositories |
| Architecture identity | Stable element IDs and typed atomic JSON relationships | EA repository or graph, with governed identity resolution |
| Retrieval | Supplied files, inspected citations and bounded questions | Search/index services that preserve source permissions |
| Human review | Recorded reviewer, disposition, date and rationale | Authenticated workflow and audit trail |
| Continuity | Validated saved JSON and generated views | Versioned storage with retention, access and recovery controls |
| Maintenance | Named steward, triggers and open-item register | Funded operating ownership and service expectations |
A JSON reviewer field is a record of supplied review information; it is not authenticated proof of approval. A schema can validate a field's shape but cannot establish enterprise truth. Access classification is a handling instruction, not an access-control mechanism.
Minimum investment case
Name the questions to support, current effort and defects, sources/owners, review capacity, evidence obligations, and operating cost. Demonstrate that retrieval and maintenance will reduce more work than they create. Start with one bounded implementation and publish its limitations.
Adoption gates
- The basic case can be completed with an inspectable brief and valid saved state.
- A correction survives a new session and the second question reuses the right knowledge.
- Reviewers can find the underlying source and explain rejected interpretations.
- A source change invalidates affected claims rather than silently preserving stale conclusions.
- A named operating owner can maintain the model and meet review commitments.
- The chosen platform's identity, permissions, retention and audit meet local requirements.
Retire or redesign integration if sources cannot remain current, reviewers have no capacity, the system cannot preserve permissions, or a simpler workflow answers the question at lower total cost.
The earlier expansive SCALE reference architecture remains available as a historical design discussion. It is not a statement of functionality implemented by the portable kit.
Inspect the full kit or return to the work.
The full reference kit contains all episodes, instructor answers, schemas, tools, and worked exports. Use the separate learner packets for an independent attempt without later evidence or answers.