Shared System Model or Digital Thread¶
Representation and trace — instantiates Concurrent Cross-Functional Integration
Connects every function's requirements, designs, decisions, interfaces, tests, and changes into one authoritative, traceable model, so everyone works from the same current state and a change's impact is visible along the links.
A Shared System Model or Digital Thread is the authoritative shared state the whole archetype references. It federates each function's artifacts — requirements, designs, decisions, interface definitions, tests, changes, releases — into one traceable model with a single authoritative-status rule and controlled local views, so no discipline works from a private shadow copy and a change's blast radius is visible along the trace links. Its defining property is authoritative traceability: it is the underlying linked model of the system, distinct from the Dependency and Change Notification Board, which is the live human surface that notifies people of change. The thread holds the truth; the board drives the action.
Example¶
A rail resignalling program spans signaling design, rolling-stock, track and civil works, operations, and safety assurance. Historically each kept its own spreadsheets and CAD, so a changed track gradient wouldn't reach the braking-curve calculations until an audit caught it — sometimes months later. They stand up a digital thread built on a model-based systems engineering backbone: requirements, the system model, interface definitions, safety cases, test results, and change records are all linked under one authoritative-status rule, with controlled local views so the signaling engineer works in their own tool mapped back to the master.
When civil revises a gradient, the trace links show exactly which braking calculations, signal spacings, and safety arguments are now invalidated — flagged stale — instead of silently drifting out of agreement. No discipline is working from a version only they can see.
How it works¶
- Map sources and assign identity. Enumerate the artifact sources, give each a stable identifier, and define one authoritative-status rule and shared terminology.
- Link dependencies and traces across requirements, design, interface, test, change, and release.
- Synchronize versions and expose change impact along the links, so an edit shows what it invalidates.
- Provide controlled local views, not uncontrolled copies, and validate trace integrity end to end.
Tuning parameters¶
- Federation scope — how many artifact domains are linked; broader coverage is more powerful but costs more integration.
- Authoritative-status strictness — a single source of truth vs. reconciled multiple sources.
- Trace granularity — coarse artifact links vs. fine clause-level traceability.
- Local-view autonomy — how much disciplines may work in their own tools, provided the mappings stay live.
- Fidelity disclosure — how explicitly the model's limits are stated, so it isn't over-trusted.
When it helps, and when it misleads¶
Its strength is killing shadow copies and stale drift: everyone references the same current state, and a change's blast radius is visible before it bites rather than discovered in an audit.
Its failure modes are a shadow copy (someone quietly works off a private version), a broken mapping between a local tool and the master, and a stale model that people stop trusting and route around. The subtlest is the dashboard-truth fallacy: the model shows green while the physical or organizational reality has moved. The classic misuse is treating the model as reality rather than a representation — trusting the digital twin over the fact on the ground. The discipline that guards against it is one authoritative-status rule, live local mappings, and periodically cross-checking the model against real evidence[n1].
How it implements the components¶
shared_reference_model_and_artifact_policy— the authoritative shared state, terminology, versioning, controlled local views, and traceability are this policy.integrated_value_stream_and_dependency_map— the linked trace graph across requirements, interfaces, and tests is the dependency model in data form (the Dependency and Change Notification Board is the live human surface over it).
It holds and traces the shared state but does not drive change notifications and owner action to closure (that's the Dependency and Change Notification Board), define or version the interface contracts themselves (Interface Control Document and Contract Test), or recombine and test the running system (Integration Build or End-to-End Increment).
Related¶
- Instantiates: Concurrent Cross-Functional Integration — the thread is the authoritative shared state all functions work from.
- Sibling mechanisms: Dependency and Change Notification Board · Interface Control Document and Contract Test · Integration Build or End-to-End Increment · Concurrent Engineering Workcell · Cross-Functional Design Review · Big-Room Planning or Concurrent Set-Based Workshop · Integrated Product or Service Team · Integrated Readiness and Release Review
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Shared System Model or Digital Thread operates as a persistent ledger, log, register, or case record that preserves history and traceability because it connects every function's requirements, designs, decisions, interfaces, tests, and changes into one authoritative, traceable model, so everyone works from the same current state and a change's impact is visible along the links.
Independent corroboration: The frozen evidence defines Shared System Model or Digital Thread as 'Connects every function's requirements, designs, decisions, interfaces, tests, and changes into one authoritative, traceable model, so everyone works from the same current state and a change's impact is visible along the links', so its operative form is Record, Log & Register.
Nearest alternative: Representation, Specification & Plan — Shared System Model or Digital Thread includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is a persistent ledger, log, register, or case record that preserves history and traceability.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: An authoritative traceable chain linking requirements, design, interfaces, tests, and changes is model-based systems engineering's digital thread.
Related originating lineages:
- Computer Science & Software Engineering — Configuration, version, and graph infrastructure implement the linked model.
- Organizational & Management Science — Shared ownership and change control keep functions working from the same baseline.
- Systems Thinking & Cybernetics — The integrated representation captures interdependencies and change propagation across the system.
Review resolution: The blind reviewers agree that engineering_design is the primary origin and differ only on domain reach disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. The broader reach of multi_domain records portability separately from historical provenance; encyclopedia_synthesis=false preserves the affirmative synthesis judgment where either reviewer identified one.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Single source of truth / digital thread — an established systems-engineering practice of maintaining one authoritative, traceable representation that all functions reference. The standing caution is the dashboard-truth fallacy: a model is a representation, not the territory, and must be cross-checked against real evidence. ↩