Skip to content

Component Model

Template Library

Component Model Template

Define major components, responsibilities, interfaces, ownership, dependencies, trust responsibilities, and explicit non-responsibilities.

ES-104 Components Responsibilities

Template purpose

Use this template to define the major components of the system and what each component is responsible for.

A component model should reduce ambiguity. Each component should have a purpose, responsibilities, inputs, outputs, interfaces, evidence responsibilities, and explicit non-responsibilities.

Project

<Project name>

Document control

Field Value
Artifact owner <owner>
Primary reviewers <reviewers>
Status <draft / in review / accepted / revised>
Last updated <YYYY-MM-DD>
Related Engineering Stage ES-104 — Architecture and Technical Approach
Project workspace target docs/project-workspace/architecture/component_model.md

Component overview

Component Responsibility Inputs Outputs Related Requirements Owner
<component> <responsibility> <inputs> <outputs> <requirements> <owner>

Component responsibilities

<Component Name>

Field Value
Purpose <purpose>
Primary Responsibilities <responsibilities>
Inputs <inputs>
Outputs <outputs>
Dependencies <dependencies>
Related Requirements <FR/NFR/C IDs>
Evidence Produced <logs, events, records, artifacts, review evidence>
Owner <owner>

Responsibilities

  • <responsibility>

Does not do

  • <explicit non-responsibility>

Failure behavior

<How this component should fail, degrade, escalate, or stop safely.>

Interfaces

Interface Components Purpose Data / Control Flow Evidence / Control
<interface> <components> <purpose> <flow> <evidence/control>

Component trust responsibilities

Component Trust Responsibility Evidence Required
<component> <access control, validation, logging, audit, AI review, escalation, privacy, safety> <evidence>
Component AI Role Human Review / Control Prohibited Behavior
<component> <none / assist / recommend / summarize / classify / generate / route> <review/control> <prohibition>

Component dependency notes

Component Dependency Risk Mitigation
<component> <dependency> <risk> <mitigation>

Open component questions

ID Question Owner Needed By
CQ-001 <question> <owner> <date or stage>

Review checklist

  • [ ] Components have clear responsibilities.
  • [ ] Component non-responsibilities are stated.
  • [ ] Interfaces are identified.
  • [ ] Inputs and outputs are described.
  • [ ] Evidence-producing components are identified.
  • [ ] AI-related components are identified or marked not applicable.
  • [ ] Failure behavior is considered.
  • [ ] Component questions are recorded.

Continue to Data and Evidence Flow

Map how data and evidence move through the architecture.

Open Data and Evidence Flow →