Engineering Documentation System

EDS — the foundation of every engineering project.

Document: 8D-RD-EDS-001
Title: Engineering Documentation Standard
Section: EDS Engineering Lifecycle
Status: Founding Release v0.1
Classification: Public Engineering Standard
Owner: 8design research and development

The Engineering Documentation System is the formal engineering framework used across research, architecture, engineering, validation, documentation, revision control, knowledge management and long-term technology development. It defines how work is structured, reviewed, traced and maintained across every current and future project.

Revision: Founding Release v0.1
Status: Public standard
Scope: Organisation-wide
Format: Controlled

If it is not documented, it is not engineered.

Documentation is an engineering discipline. Every significant decision, assumption, validation, revision and implementation should be traceable throughout the complete engineering lifecycle.

Controlled document

Download the engineering standard

A PDF copy of 8D-RD-EDS-001 — Engineering Documentation Standard, Founding Release v0.1 — for offline review, internal distribution and citation in project documentation.

Ref.: 8D-RD-EDS-001
Revision: v0.1
Format: PDF · A4
Size: 27 KB

Download PDF

EDS Engineering Lifecycle

The EDS engineering lifecycle defines the mandatory structure through which projects are framed, researched, architected, engineered, validated, documented and extended. Each phase follows the same internal documentation standard so that engineering work remains comparable, reviewable and reproducible across the organisation.

Problem Definition & Context

Frame the engineering problem in measurable terms, establish operating context and distinguish assumptions from validated facts.

Purpose: To define the engineering problem clearly before any architecture, implementation or solution preference is introduced.
Objectives: Describe the problem environment, constraints and stakeholders.
Separate hypotheses, observations and verified requirements.
Record why the problem matters in long-term engineering terms.
Inputs: Initial observations, stakeholder context, domain constraints, field notes and prior issue statements.
Outputs: A structured engineering problem statement with traceable boundaries, assumptions and success conditions.
Deliverables: Problem statement, context model, assumptions register, requirement baseline and constraint overview.
Engineering Considerations: Avoid premature solution bias. Ensure terminology, system boundaries and measurable conditions are stable enough for review.
Typical Documentation Produced: Problem definition document, context analysis, baseline requirement notes and terminology register.
Expected Review Criteria: The problem is stated unambiguously, bounded correctly and supported by traceable evidence rather than intuition alone.
Future Related Documents: Context reports, requirement registers, domain glossaries and stakeholder records.

Research Scope & Objectives

Define what must be investigated, what falls outside the study and which engineering questions govern the research phase.

Purpose: To convert the defined problem into a controlled research scope with explicit engineering objectives.
Objectives: Set the research boundaries and exclusions.
Establish the questions that must be answered before architecture work begins.
Define evidence expectations and decision thresholds.
Inputs: Approved problem definition, domain constraints, strategic priorities and initial knowledge gaps.
Outputs: A documented research scope with engineering objectives, exclusions and expected lines of inquiry.
Deliverables: Research scope document, objective matrix, exclusion list and investigation plan.
Engineering Considerations: Research objectives should support downstream architecture, validation and revision decisions rather than broad exploratory writing.
Typical Documentation Produced: Research scope, objective register, investigation brief and evidence planning notes.
Expected Review Criteria: Objectives are specific, technically relevant and proportionate to the defined problem and future engineering decisions.
Future Related Documents: Research briefs, objective matrices, literature plans and decision framing notes.

State of the Art

Assess relevant prior work, standards, methods, systems and engineering precedents across adjacent disciplines.

Purpose: To position the project within existing technical knowledge and identify what is established, missing or insufficient.
Objectives: Review comparable systems, standards and publications.
Identify validated practices and known limitations.
Determine where genuine engineering novelty or adaptation is required.
Inputs: Research objectives, literature sources, standards references, prior implementations and domain publications.
Outputs: A structured state-of-the-art assessment linked to the project problem and research scope.
Deliverables: State-of-the-art review, comparative matrix, standards inventory and gap analysis.
Engineering Considerations: References should be evaluated for applicability, maturity, reproducibility and system relevance rather than collected superficially.
Typical Documentation Produced: Literature review, comparative tables, reference annotations and standards mapping.
Expected Review Criteria: The review is technically grounded, current enough for the domain and explicit about where existing approaches are insufficient.
Future Related Documents: Reference library, standards index, comparative analyses and technology survey appendices.

System Architecture

Define the top-level system structure, functional boundaries, interfaces, dependencies and architectural responsibilities.

Purpose: To establish the governing system model that aligns research findings with an implementable engineering structure.
Objectives: Decompose the system into coherent elements.
Specify interfaces, boundaries and dependencies.
Create an architecture that supports traceable engineering decisions.
Inputs: Problem context, research outcomes, state-of-the-art findings, requirements and system constraints.
Outputs: A documented architecture baseline describing components, interfaces, data or signal paths and system responsibilities.
Deliverables: Architecture document, interface definitions, decomposition diagrams and dependency map.
Engineering Considerations: Architecture should make assumptions explicit, maintain separation of concerns and remain reviewable before detailed design begins.
Typical Documentation Produced: Architecture records, interface specifications, decomposition views and system boundary descriptions.
Expected Review Criteria: The architecture is internally coherent, technically justified and sufficiently complete to guide detailed engineering design.
Future Related Documents: Architecture decision records, interface registries, system maps and dependency analyses.

Engineering Design

Translate architecture into engineering design decisions for components, interactions, constraints and performance behaviour.

Purpose: To define how each architectural element will operate, interact and satisfy the system intent in engineering terms.
Objectives: Describe component behaviour and responsibilities.
Resolve key design constraints and trade-offs.
Support downstream specification and implementation planning.
Inputs: Approved architecture, interface definitions, constraints, applicable standards and design assumptions.
Outputs: A detailed design baseline for components, interactions and engineering trade-offs.
Deliverables: Design descriptions, component analyses, decision records and trade-off evaluations.
Engineering Considerations: Design decisions should remain traceable to the architecture and research evidence, with alternatives documented where relevant.
Typical Documentation Produced: Engineering design notes, component descriptions, decision registers and design rationale appendices.
Expected Review Criteria: Design choices are technically defensible, compatible with architecture constraints and sufficiently precise for specification work.
Future Related Documents: Component dossiers, interface refinements, design reviews and engineering decision records.

Engineering Specification

Convert the design baseline into a reproducible specification suitable for implementation, testing and future revision.

Purpose: To produce the controlled technical specification against which engineering work and validation can proceed.
Objectives: Define exact engineering requirements, tolerances and interfaces.
Eliminate ambiguity in implementation expectations.
Prepare the foundation for controlled verification and revision management.
Inputs: Design baseline, architecture records, standards references, constraints and review feedback.
Outputs: A formal engineering specification with traceable requirements and reproducible implementation guidance.
Deliverables: Technical specification, requirement tables, interface definitions, parameter sets and acceptance references.
Engineering Considerations: Specification language must remain precise, testable and revision-safe. Undefined behaviour should be treated as a defect in the document.
Typical Documentation Produced: Specifications, requirement matrices, parameter registers and controlled revision notes.
Expected Review Criteria: The specification is complete enough for independent implementation and stable enough to support validation planning.
Future Related Documents: Requirement baselines, specification annexes, parameter libraries and revision histories.

Risk Analysis

Evaluate failure modes, operational risks, security concerns, constraints and foreseeable engineering uncertainties.

Purpose: To identify technical risk early and document the mitigation logic before implementation begins.
Objectives: Analyse failure modes and threat conditions.
Record mitigation strategies and residual risks.
Support safe and reviewable engineering progression.
Inputs: Architecture, design, specification, environmental constraints, threat models and historical failure knowledge.
Outputs: A documented risk position with explicit mitigations, unresolved concerns and review priorities.
Deliverables: Risk register, failure analysis, mitigation plan, security notes and residual risk summary.
Engineering Considerations: Risks should be tied to specific system conditions, not abstract warnings. Residual uncertainty must remain visible for future revisions.
Typical Documentation Produced: Risk analyses, hazard notes, security assessments, mitigation tables and review memoranda.
Expected Review Criteria: Major risks are identified, ranked, technically contextualised and linked to realistic mitigation or monitoring actions.
Future Related Documents: Threat models, safety analyses, mitigation plans and review follow-up records.

Verification & Validation

Define how compliance, behaviour and performance will be checked against documented engineering criteria.

Purpose: To establish the formal basis on which the project can be evaluated, accepted, rejected or revised.
Objectives: Define criteria, methods and measurable outcomes.
Separate verification of conformance from validation of intended behaviour.
Ensure all evaluation logic is documented before testing begins.
Inputs: Engineering specification, risk analysis, performance targets, measurement constraints and acceptance conditions.
Outputs: A structured validation framework with traceable criteria, methods and expected evidence.
Deliverables: Validation plan, verification matrix, test method definitions, measurement plan and acceptance criteria.
Engineering Considerations: Validation should be repeatable, evidence-based and aligned with actual operating conditions wherever possible.
Typical Documentation Produced: Validation protocols, verification matrices, test procedures, measurement records and acceptance reports.
Expected Review Criteria: Methods are reproducible, criteria are measurable and the evidence strategy is adequate for engineering decision-making.
Future Related Documents: Test plans, protocol annexes, measurement templates and validation evidence repositories.

Prototype Implementation

Implement a prototype against the documented specification and record deviations, observations and measured outcomes.

Purpose: To materialise the documented engineering work in a controlled prototype that can be evaluated and revised.
Objectives: Implement according to the controlled specification.
Document deviations, constraints and observed behaviour.
Generate evidence for future revision or scaling.
Inputs: Approved specification, validation plan, risk controls, component definitions and implementation constraints.
Outputs: A prototype and a documented implementation record linked to the governing engineering documents.
Deliverables: Prototype build, implementation log, deviation record, measurement results and engineering observations.
Engineering Considerations: Prototype work should not bypass documentation discipline. Any divergence from specification requires traceable explanation.
Typical Documentation Produced: Implementation reports, build records, deviation logs, test observations and revision notes.
Expected Review Criteria: The prototype can be traced back to the specification, observed deviations are recorded and results are technically interpretable.
Future Related Documents: Build logs, implementation baselines, deviation reports and validation result sets.

Future Development Roadmap

Define how the work can evolve through further research, refinement, scaling, revision and long-term technology development.

Purpose: To preserve continuity after the prototype stage and ensure knowledge remains actionable for future engineering work.
Objectives: Identify next engineering priorities and limitations.
Convert findings into structured future work.
Maintain continuity across revisions and related projects.
Inputs: Prototype findings, validation evidence, unresolved risks, design limitations and strategic research priorities.
Outputs: A roadmap that links current findings to future revisions, research programmes and engineering development.
Deliverables: Roadmap document, next-step priorities, open engineering questions and future revision recommendations.
Engineering Considerations: The roadmap should distinguish validated conclusions from hypotheses, and immediate follow-up from long-range research directions.
Typical Documentation Produced: Roadmaps, revision proposals, future work registers and continuity notes.
Expected Review Criteria: Future work is prioritised, grounded in documented evidence and connected to the lifecycle without breaking traceability.
Future Related Documents: Roadmap revisions, future research briefs, backlog registers and continuity reports.

Framework Scope

EDS is not limited to document formatting or archival practice. It is the governing engineering framework through which research, architecture, engineering, validation and continuity are controlled as one traceable system.

Research

Research questions, evidence gathering and technical positioning are documented under the same controlled standard as engineering work.

Architecture

Architectural decisions are treated as governed engineering artefacts with explicit boundaries, interfaces and review points.

Engineering

Design, specifications and implementation records remain traceable across revisions, dependencies and future development stages.

Validation

Verification methods, criteria, measurements and conclusions are formal parts of the documentation system rather than separate afterthoughts.

Documentation

Documentation is treated as a primary engineering output that defines, records and preserves technical decisions.

Revision Control

Each controlled artefact carries revision identity, change discipline and documented approval history.

Knowledge Management

Engineering knowledge is stored in a reusable structure so later teams, projects and publications can inherit validated work.

Long-term Technology Development

Roadmaps, unresolved questions and future research directions remain connected to the originating engineering evidence.

Revision Control & Knowledge Management

Controlled revisions

Every standard, specification, report and project artefact carries a revision identity, publication status and dated change history.

Review discipline

Substantive revisions pass documented review before they become governing references for future engineering work.

Knowledge continuity

Documents preserve rationale, assumptions and evidence so future projects inherit validated knowledge rather than isolated conclusions.

Validation Methodology

Validation criteria are defined before implementation. A prototype is not considered validated because it appears to work; it is considered validated only when it satisfies documented criteria, under documented conditions, with documented measurements and a reviewable conclusion.

V.1

Criteria

What must be demonstrated.

V.2

Method

How evaluation is performed.

V.3

Measurement

Which evidence is collected.

V.4

Conclusion

Whether the result satisfies the standard.