Repository Tour¶
Purpose¶
This page explains how the Starter Kit repository is organized.
The repository is designed like an engineering workbench. It separates guidance, templates, examples, internal platform support, and project-specific evidence so teams can see what to read, what to copy, what to compare, and what to complete.
Repository model¶
Engineering Platform → learn the process
Template Library → copy a starting point
Examples → study completed evidence
Project Workspace → produce your project's evidenceWhy docs/project-workspace/ exists¶
This repository uses docs/ as the MkDocs publication root for GitHub Pages. That means docs/ contains the website and platform documentation.
For project evidence, the Starter Kit uses a dedicated workspace:
docs/project-workspace/
That keeps platform documentation separate from the evidence created for a cloned project.
Main directories¶
docs/platform/
Guided onboarding for the Starter Kit: what it is, how to use it, the lifecycle, repository tour, and quick start.
docs/engineering/
Public Engineering Stage guidance for ES-100 through ES-114, including activities, evidence, outputs, gates, and manifests.
docs/template-library/
Reusable artifact templates. Copy templates into the project workspace, then complete them for your system.
docs/examples/
Completed reference examples, including LMU/COICP, that show how ETIS evidence may look in practice.
docs/project-workspace/
The project evidence workspace where a cloned project records vision, requirements, architecture, testing, operations, monitoring, and stewardship evidence.
docs/platform-design/
Internal platform architecture and design records. This supports platform maintenance and is not part of the public guided workflow.
What not to confuse¶
| Area | Use | Do not |
|---|---|---|
docs/platform/ |
Learn how to adopt the Starter Kit | Treat onboarding pages as project evidence |
docs/engineering/ |
Read Engineering Stage guidance | Edit stage guidance for one project |
docs/template-library/ |
Copy reusable templates | Complete project evidence in the template source |
docs/examples/ |
Compare completed examples | Copy example decisions blindly |
docs/project-workspace/ |
Store completed project evidence | Mix platform documentation with project artifacts |
docs/platform-design/ |
Maintain internal platform architecture | Add it to public navigation unless intentionally productized |
Project workspace evidence families¶
docs/project-workspace/
├── vision/
├── requirements/
├── planning/
├── architecture/
├── design/
├── implementation/
├── integration/
├── testing/
├── release/
├── operations/
├── deployment/
├── monitoring/
├── stewardship/
└── governance/
Public and internal boundaries¶
Public-facing guidance belongs under docs/platform/, docs/engineering/, docs/template-library/, and docs/examples/.
Internal platform support files should remain internal unless intentionally surfaced through navigation. In particular:
docs/engineering/_shared/
docs/platform-design/
should not be treated as ordinary public navigation sections.
Daily working model¶
Most users should rarely modify the Engineering Platform, Template Library, or Examples. Those areas are the reference library.
Most project-specific engineering work should occur in:
docs/project-workspace/
Think of the rest of the repository as the engineering reference library and the project workspace as the engineering notebook for the system being built.
Do not edit the template library as if it were your project evidence. Templates are reusable starting points; completed evidence belongs in docs/project-workspace/.
A well-structured repository makes the system’s engineering history reviewable instead of recoverable only through memory.