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

4. Formatting Standards

RFC-RFCSTD-0002                                                   Section 4
Category: Standards Track                           Formatting Standards

4. Formatting Standards

← Structure | Index | Next →


4.1 Document Header

Each file in an Architecture RFC MUST begin with:

RFC- Section N Category:


# N. Section Title

[← Previous](./prev.md) | [Index](./00-index.md) | [Next →](./next.md)

---

4.2 Diagram Requirements

Architecture RFCs SHOULD include diagrams for:

ConceptDiagram TypeRequired
System overviewflowchartRECOMMENDED
Trust boundariesflowchartCONDITIONAL (if security-relevant)
Data flowssequenceDiagramRECOMMENDED
State transitionsstateDiagram-v2OPTIONAL
Component relationshipsflowchartRECOMMENDED

All diagrams MUST use Mermaid syntax.


4.3 Invariant Format

Invariants MUST follow this format:

### Invariant N — Short Title
 
Statement using RFC 2119 keywords (MUST, MUST NOT, etc.).
 
Explanation of why this invariant exists and consequences of violation.

Example:

### Invariant 3 — Secret Authority
 
HashiCorp Vault MUST be the sole authoritative source for secrets
required by platform applications.
 
No application MAY store authoritative secrets outside of Vault.
Kubernetes Secrets exist only as derived artifacts synchronized
by External Secrets Operator.
 
This invariant ensures centralized secret lifecycle management
and auditability. Violation would create untracked secrets
outside the rotation and audit framework.

4.4 Trust Boundary Format

Trust boundaries SHOULD be illustrated using Mermaid flowcharts with subgraphs:


4.5 Component Format

Components SHOULD be documented using tables:

### Component Name
 
| Aspect | Description |
|--------|-------------|
| Responsibility | What this component does |
| Inputs | What it receives |
| Outputs | What it produces |
| Dependencies | What it requires |
| Failure Mode | How it fails |
| Recovery | How it recovers |

4.6 Rejected Alternative Format

Rejected alternatives MUST follow this format:

### N.N.N Alternative Name
 
**Description**: What the alternative is.
 
**Why It Was Attractive**:
- Genuine benefit 1
- Genuine benefit 2
 
**Why It Was Rejected**:
- Specific failure or limitation 1
- Specific failure or limitation 2
- Violates Invariant N (if applicable)
 
**Conclusion**: Summary judgment.

Each file MUST include navigation links after the header:

[← Previous](./prev.md) | [Index](./00-index.md) | [Next →](./next.md)

The index file uses:

[Index](./00-index.md) | [Next →](./01-introduction.md)

4.8 Section Separators

Use horizontal rules (---) to separate:

UsagePlacement
After navigation linksBefore content begins
Before section footerAfter content ends
Between major subsectionsWhen logical break needed

End of Section 4 — RFC-RFCSTD-0002

On this page