Canonical Technical Definition

A formal engineering proposal document that outlines a technical architecture, protocol, or system change to solicit feedback and achieve consensus before implementation.

A Request for Comments (RFC) is an authoritative technical design proposal used by engineering organizations to document, review, and achieve consensus on major architectural decisions before committing engineering resources to code.

Originating in 1969 with the creation of the ARPANET—the foundational infrastructure of the modern internet—the RFC process has become the premier standard for high-performance software teams at companies like Amazon, Stripe, Uber, and Meta.

The purpose of the RFC process

Writing an RFC transforms software engineering from reactive code hacking into deliberate system design:

  1. Fleshing out edge cases early: Code is expensive to write and ten times more expensive to rewrite. Describing a system in a 5-page RFC forces authors to confront database scale limits, failure modes, and migration hazards while changes are free.
  2. Asynchronous peer review: RFCs allow cross-functional engineers (security, reliability, frontend, infrastructure) to review designs on their own schedule without endless synchronous meetings.
  3. Institutional architectural memory: Two years after a system ships, new hires can read the original RFC to understand why specific trade-offs were chosen and which alternative designs were rejected.

Standard anatomy of an engineering RFC

An effective RFC document follows a structured format:

# RFC 0042: Local On-Device Transcription Pipeline

- **Author:** Marcus Vance
- **Status:** Draft / In Review / Approved
- **Created:** 2026-10-09

## 1. Summary
A 2-paragraph overview of the proposed architectural change.

## 2. Motivation & Problem Statement
Why does our current architecture fail? What user pain points are we solving?

## 3. Detailed Technical Design
- Ingestion: ScreenCaptureKit audio buffer pipeline
- Processing: Core ML Whisper execution on Apple Neural Engine
- Storage: Standard CommonMark plain files on local disk

## 4. Trade-offs & Rejected Alternatives
- Rejected: Cloud API transcription (rejected due to privacy and ongoing API cost).
- Rejected: Virtual audio driver (rejected due to kernel panic risks).

## 5. Security & Privacy Considerations
Threat model analysis detailing network egress isolation.

## 6. Implementation Milestones
Phased rollout plan with target completion dates.

Managing RFCs in Oyma

In Oyma on macOS:

  • RFCs exist as clean Markdown documents in your engineering notes repository.
  • Bidirectional [[WikiLinks]] connect RFCs directly to meeting minutes, customer interviews, and architectural post-mortems.
  • When architecture review calls occur, Oyma transcribes attendee feedback and questions, allowing the author to update the RFC in place.

Frequently asked questions about Request for Comments (RFC) Process

Where did the term RFC originate?

The RFC process was invented in 1969 by Steve Crocker to develop the ARPANET (the precursor to the internet), published as RFC 1. It is now managed by the Internet Engineering Task Force (IETF).

What is the purpose of an internal engineering RFC?

Internal RFCs force engineers to think through architectural edge cases, security implications, and scaling limits in writing before writing expensive code, building organizational consensus.

How does storing RFCs in plain Markdown benefit engineering teams?

Markdown RFCs live directly in version-controlled repositories (Git), allowing engineers to review designs using standard pull requests, code reviews, and bidirectional links.