Book 2 of The Architect’s Playbooks
The Digital Thread Playbook
Practical MBSE and Digital Engineering for Defense and Space Programs
A practitioner’s guide to MBSE on defense and space programs: build the digital thread, earn the digital twin, measure what works.
Full masterclass · Free
Watch the full masterclass.
The full hour-long masterclass drawn from this book — narrated by an AI voice, written by Dr. Daryoush Tehranchi. The running example, Program Larkspur, is fictional.
FREE · 1 hour · 10 chapters
About the book
What actually changes when the documents become a model.
Early in his career, the author watched a satellite communications program manage roughly four hundred interface control documents — each a static snapshot of an agreement between two teams, each already slightly wrong by the time it was approved, because the system had kept changing while the document was in review. Nobody had done anything wrong. That was simply what systems engineering looked like before the tools existed to do it differently.
That structural flaw — a document is accurate only at the moment it’s written, and quietly drifts from the system every day after — is why defense and intelligence programs are moving from documents to models. The Digital Thread Playbook is a practitioner’s account of what actually changes when a defense or space program makes that move, written by someone who has built digital threads on real, classified, multi-contractor programs, watched them succeed, and watched pieces of them fail. It is deliberately not a tool manual: it’s about the judgment underneath the tools that determines whether model-based systems engineering actually works on a live program.
The book shows how to:
- Build a digital thread that runs from concept of operations through verification — joint by joint, each traceable link deliberately designed
- Tell a digital twin from a static model, and know when to earn the name — and when to decline to build one at all
- Choose a modeling toolchain with a bounded two-week pilot against your real interoperability requirement, not a feature comparison
- Pick DoDAF or UAF — and the specific viewpoints that earn their place — based on who the architecture has to communicate with
- Build modular open systems architectures that are open in substance, not just open in name
- Enforce layer boundaries as an actual discipline, so a layer can’t silently depend on implementation details the interface never contracted
- Catch defects in model-based verification weeks before integration testing would find them
- Judge AI-generated model content by semantic correctness, not structural polish
- Run a deliberate hybrid program where document-based and model-based practice coexist by design
- Bring a legacy program into digital engineering without pretending the transition is greenfield
- Measure whether the investment is actually working — with leading indicators, not a handful of good stories
You don’t need to have read The Chief Architect’s Playbook first. But if you have, you’ll recognize the same voice, the same insistence on judgment over process — and it closes with twelve rules, and a final word on what outlasts the tools.
Key takeaways
Six ideas worth keeping.
Takeaway 01
Model-based means one authoritative model, not a stack of documents.
Every artifact that used to be a separate document becomes a view generated from the same connected model. Change a requirement and everything downstream that traces to it is either updated automatically or flagged for review, instead of going quietly stale. That’s the difference between an interface mismatch surfacing in a design review, where it costs an afternoon, and surfacing in integration testing, where it costs weeks and the customer’s trust. (Chapter 1)
Takeaway 02
A digital twin is earned, not promised.
The thread is the connected data backbone; the twin is a live, synchronized virtual representation built on top of it. A beautifully detailed model that never gets updated against real operational or test data is a digital model — useful, but not a twin, and calling it one sets an expectation the effort can’t deliver. And if a subsystem is stable and being retired within eighteen months, declining to build a twin for it is the more rigorous call. (Chapters 2 and 9)
Takeaway 03
Choose your modeling toolchain with a bounded two-week pilot.
A paper comparison tells you what a tool can theoretically do; a two-week pilot against a real slice of your architecture tells you what it actually costs to make the tool work inside your program. Structure the process to allow the honest, unwelcome answer: that neither candidate is adequate. And keep the parts of your thread that matter most expressed close to the SysML standard, not a vendor’s proprietary extensions. (Chapter 3)
Takeaway 04
Openness that isn’t governed is openness in name only.
Genuine modular open systems architecture needs components that can be developed and upgraded independently, published interfaces any qualified vendor can build against — and a governance body no single participant can override unilaterally. An interface that’s technically published but controlled by one vendor is a proprietary interface with good documentation. (Chapter 5)
Takeaway 05
A model can be structurally valid without being semantically correct.
An AI-assisted tool generated a SysML diagram that was clean, syntactically valid, and semantically wrong in a way only a reviewer with deep domain knowledge could spot. That’s the more dangerous failure mode than a bad paragraph: a flawed model propagates through the same automated traceability the digital thread is built to provide. No AI-generated model element enters the authoritative thread without a domain expert’s explicit review and sign-off. (Chapter 8)
Takeaway 06
Judge the digital engineering investment by leading indicators, not stories.
The clearest wins of a digital thread are counterfactual — the mismatch caught in a model review instead of integration testing — which is exactly why anecdote-based evidence isn’t enough for a budget decision. Track the percentage of requirements changes that trigger an automated downstream flag, the time between a design change and its reflection in the model, and the ratio of defects caught in model review versus physical integration. (Chapters 10 and 12)
Who it’s for
For the person responsible for making MBSE actually work.
Questions
Before you ask.
Our program just got a mandate to go model-based, but we don’t have the tooling or training yet. Where do we start?
Don’t try to convert the whole program at once — and don’t fake full compliance. Scope the thread to the specific deliverable that has to trace requirements through verification in a connected model, leave the rest running document-based in parallel, and be explicit with the customer, in writing, about what is and isn’t converted and why.
Is this a tool manual?
Deliberately not. The book names real tools and languages but writes about the judgment required to use them, not version-specific features — because any comparison would be stale by the time you read it. What you get instead is the decision discipline: a bounded two-week pilot against your program’s actual interoperability requirement.
Do I need to have read The Chief Architect’s Playbook first?
No. This book stands alone — it goes underneath that book’s leadership layer into the technical practice. There are callbacks to ideas the first book only gestured at, but nothing here assumes you’ve read it.
Our program has a decade of documents and an existing system in the field. Is legacy conversion covered?
Yes — Chapter 11 is written for exactly that. Retrofitting is not greenfield with extra steps. Prioritize conversion by where the thread pays off fastest, treat the boundary between converted and unconverted portions as a managed interface, and know when stopping partway is the more disciplined call.
I’m a program manager, not an engineer. Is this book for me?
Yes — Chapter 12 is written most directly for that reader, answering “how do we actually know this is working?” with real measurement discipline: leading indicators tracked from early in the effort. No modeling background required.
The author
Dr. Daryoush Tehranchi is an engineer, architect, educator, and author whose work focuses on complex systems, systems and software architecture, digital engineering, artificial intelligence, technical leadership, and the decisions that remain fundamentally human.
The Architect’s Playbooks
More from the series.
Connect with Daryoush