ProficientNowTechRFCs
RFC Standards/RFC Kinds/Architecture/RFC RFCSTD 0002

2. Normative Requirements

RFC-RFCSTD-0002                                                   Section 2
Category: Standards Track                          Normative Requirements

2. Normative Requirements

← Scope | Index | Next →


2.1 Invariant Specification Requirement

Architecture RFCs MUST define at least one architectural invariant.

Each invariant MUST:

RequirementDescriptionVerification
Be numberedFormat: Invariant N — TitleCheck for numbered format
Use RFC 2119 keywordsMUST, MUST NOT, SHOULD, etc.Search for keywords
Be falsifiablePossible to determine if violatedReview for testability
Include rationaleExplain why invariant existsCheck for explanation

2.2 Trust Boundary Requirement

Architecture RFCs SHOULD define trust boundaries when the architecture involves:

ScenarioTrust Boundary Required
Multiple systems or componentsSHOULD
Security-sensitive operationsMUST
Authorization decisionsMUST
Data flow between domainsSHOULD

Trust boundaries SHOULD be illustrated using Mermaid diagrams.


2.3 Rationale Requirement

Architecture RFCs MUST include a Rationale section documenting:

ComponentRequirement
Alternatives consideredAt least one alternative
Why alternatives were rejectedSpecific reasons
Invariant violationsWhich invariants each alternative violated (if applicable)

2.4 Component Interface Requirement

Architecture RFCs SHOULD define component interfaces including:

Interface AspectDescription
Inbound interfacesWhat the component receives
Outbound interfacesWhat the component produces
Failure modesHow the component fails
Recovery expectationsHow the component recovers

2.5 Non-Implementation Requirement

Architecture RFCs MUST NOT contain:

ProhibitedPermitted Alternative
Working code in any programming languagePseudocode for conceptual illustration
Configuration files (YAML, JSON, TOML, etc.)Structural descriptions
Shell commands or scriptsCapability descriptions
Database schemas with actual field valuesSchema concepts without values
API endpoint implementationsAPI contracts (input/output only)

Permitted in code blocks:

PermittedPurpose
Mermaid diagramsVisual representation
Format specifications (structure only)Showing expected formats
Placeholder examples with obviously non-functional valuesIllustrating concepts

2.6 Multi-File Requirement

Architecture RFCs MUST be organized as multi-file directories.

Rationale: Architecture RFCs are inherently complex and benefit from:

  • Clear section boundaries
  • Focused reading paths
  • Easier navigation
  • Independent section review

2.7 Diagram Requirement

Architecture RFCs SHOULD include diagrams for:

ConceptDiagram Type
System overviewflowchart
Trust boundariesflowchart with subgraphs
Data flowssequenceDiagram
State transitionsstateDiagram-v2
Component relationshipsflowchart

All diagrams MUST use Mermaid syntax. All diagrams MUST be indexed in Appendix A.


End of Section 2 — RFC-RFCSTD-0002

On this page