Skip to content

Interface Design

Template Library

Interface Design Template

Define interface contracts, validation rules, authorization, error behavior, evidence produced, compatibility expectations, and downstream verification needs.

ES-105 Interfaces Contracts

Template purpose

Use this template to define the interfaces that connect users, components, services, workflows, external systems, AI capabilities, and evidence stores.

An interface design should be explicit enough that implementation and testing teams understand inputs, outputs, validation, authorization, error behavior, evidence, compatibility, and ownership.

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-105 — Detailed Design
Project workspace target docs/project-workspace/design/interface_design.md

Interface register

ID Interface Caller Provider Purpose Inputs Outputs Authorization Evidence Produced
IF-001 <interface> <caller> <provider> <purpose> <inputs> <outputs> <auth rule> <evidence>

Interface details

IF-001 — <Interface Name>

Field Value
Purpose <purpose>
Caller <caller>
Provider <provider>
Interaction Type <UI / API / event / file / database / message / AI interaction / manual handoff>
Related Requirements <FR/NFR/C IDs>
Related Components <components>
Owner <owner>

Input contract

<input fields / payload / request / event / user action>

Output contract

<output fields / response / event / confirmation / evidence>

Validation rules

Rule ID Rule Failure Behavior
VAL-001 <rule> <failure behavior>

Authorization rules

Action Required Role / Condition Denied Behavior
<action> <role or condition> <denied behavior>

Error behavior

Error Response Evidence / Log
<error> <response> <evidence>

Evidence produced

Evidence Trigger Storage / Review
<evidence> <trigger> <location or review>

Compatibility and versioning

<Versioning, backward compatibility, migration, or deprecation considerations.>

Security and privacy considerations

<Access control, data minimization, sensitive fields, privacy, logging restrictions.>

Test implications

<Tests, contract checks, integration checks, or review evidence needed.>

Open interface questions

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

Review checklist

  • [ ] Interfaces have owners.
  • [ ] Inputs and outputs are defined.
  • [ ] Validation rules are explicit.
  • [ ] Authorization rules are explicit.
  • [ ] Error behavior is defined.
  • [ ] Evidence produced is identified.
  • [ ] Security and privacy concerns are considered.
  • [ ] Test implications are identified.

Continue to Data Design

Define entities, fields, relationships, evidence fields, access restrictions, and retention.

Open Data Design →