Every large engineering organisation eventually develops the same problem. Two engineers sit in the same design review, look at the same diagram, and mean entirely different things when one says "this doesn't scale" and the other says "the coupling is wrong." The discussion that follows isn't an engineering conversation. It's a vocabulary negotiation.
The same problem now extends to AI tools. When you ask Claude, Copilot, or ChatGPT to review your code or design a system, the AI responds in its own vocabulary — often vague, often correct, never precise. It will say "consider caching" instead of "AT4 — choosing precomputation, but FM7 is real on cold start." It will say "this could be a bottleneck" instead of "FM6 — this cache key is not user-scoped, so all requests route to the same shard."
The Computing Series was built around a single premise: nine frameworks, expressed in a shared shorthand, can replace most of that negotiation — between engineers, and between engineers and their AI tools.
Using this vocabulary with AI coding tools
The vocabulary tables in this article are designed to be injected directly into any AI tool's context window. When Claude, Copilot, ChatGPT, or Codex has the framework codes available, the quality of its responses changes immediately.
Without the vocabulary:
"You might want to add caching here to improve performance."
With the vocabulary:
"AT4 — precomputation is the right call here. The read path is hot and the data changes infrequently. That said, FM7 is real: if the cache is cold-started under load (deploys, incidents), you'll hit the database with full traffic simultaneously. Mitigation: warm the cache before traffic is routed, or use a staggered TTL per key."
The second response names the tradeoff, names the failure mode, and gives a concrete mitigation. You can argue with it. You can say "the data changes frequently, AT4 doesn't apply" and the AI will re-evaluate at the right level — the tradeoff — rather than re-explaining what caching is.
How to enable this in your AI tool:
For Claude or ChatGPT: paste the vocabulary file into the conversation as context before asking design questions. Or add it to a custom instruction / system prompt so it's always available.
For GitHub Copilot or Cursor: add the vocabulary to a .github/copilot-instructions.md file or workspace context. Copilot will then use the codes in its inline suggestions and review comments.
For team Claude Code setups: add to CLAUDE.md in your repository root. Every engineer on the team gets the same vocabulary injected automatically into every Claude Code session.
The prompt addition is simple:
When discussing design decisions, architecture, or code review findings,
use AT/FM/T/P/L codes from The Computing Series vocabulary. Name the
tradeoff (AT[N]), name the failure mode (FM[N]), suggest the pattern (T[N]).
How the vocabulary works in practice
In a code review:
FM8 here — the frontend assumes the API always returns
user.rolebut I don't see that guaranteed in the contract. If the backend team changes this field the frontend breaks silently.
In an architecture decision record (ADR):
Decision: pre-compute the user feed at write time. Tradeoff: AT4 — choosing precomputation because read latency matters more than write cost at this scale. Exposes: FM7 — cache stampede on cold start. Mitigation: lazy warm-up with staggered TTLs per user cohort.
In an oncall handoff:
FM11 on the payments retry queue. No metric for queue depth. No alert if it stops draining. If the worker process dies we won't know until customer complaints arrive.
In a system design review (the seven questions):
Before any architecture is declared complete, these questions surface what the design is hiding:
- How does it scale? What breaks at 10x current load? (FM3, FM6)
- How does it fail? What happens when each component is unavailable? (FM1, FM2)
- Where is the state? Can it replicate? What happens on divergence? (FM4, FM12)
- What is the latency budget? How many network hops? What is the P99? (FM5)
- How does it evolve? Can schemas and APIs change without breaking consumers? (FM8)
- How is it secured? What has access to what? Are credentials in environment, not code? (FM10)
- Can you observe it? If it fails at 3 AM, can oncall diagnose it from metrics, logs, traces? (FM11)
The most commonly skipped question is the last one. It is also the one that makes every other failure mode worse.
The nine frameworks — complete reference
AT — Architecture Tradeoffs
Every design decision resolves a tradeoff. Naming the tradeoff before writing code is the difference between a conscious decision and an accidental one.
| Code | Name | You are choosing between |
|---|---|---|
| AT1 | Consistency vs Availability | Correct data vs system stays up |
| AT2 | Latency vs Throughput | Speed per request vs requests per second |
| AT3 | Simplicity vs Flexibility | Easy to understand vs easy to extend |
| AT4 | Precomputation vs On-Demand | Pay at write time vs pay at read time |
| AT5 | Centralisation vs Distribution | Single authority vs no single point of failure |
| AT6 | Generality vs Specialisation | All cases vs common case optimised |
| AT7 | Automation vs Control | System decides vs human decides |
| AT8 | Coupling vs Cohesion | Independent deployment vs co-located logic |
| AT9 | Correctness vs Performance | Right answer vs fast answer |
| AT10 | Synchronous vs Asynchronous | Immediate response vs deferred processing |
Standard decision block format:
Decision: [what you chose]
Tradeoff: AT[N] -- choosing [pole] because [reason]
Exposes: FM[N] -- [what could go wrong]
Mitigation: [how the failure mode is addressed]
FM — Failure Modes
Every component introduces at least one way the system can fail. Name it before shipping.
| Code | Name | What goes wrong |
|---|---|---|
| FM1 | Single Point of Failure | One component dies, system dies |
| FM2 | Cascading Failures | One failure triggers the next |
| FM3 | Unbounded Resource Consumption | Memory / connections / threads grow without limit |
| FM4 | Data Consistency Failure | Components disagree on state |
| FM5 | Latency Amplification | Small latencies multiply across hops |
| FM6 | Hotspotting | One node gets disproportionate load |
| FM7 | Thundering Herd | Mass simultaneous retry overwhelms recovery |
| FM8 | Schema / Contract Violation | One side of a boundary changes, other side breaks |
| FM9 | Silent Data Corruption | Wrong data propagates without alerts |
| FM10 | Security Breach | Unauthorised access to data or compute |
| FM11 | Observability Blindness | System fails but team cannot see where |
| FM12 | Split-Brain | Two nodes both think they are primary |
FM8 is the most common failure in teams that move fast. API contracts drift. Environment variables get renamed. Config keys change. Each is a contract violation that passes all tests and breaks in production.
T — Threads (Structural Patterns)
Twelve structural patterns appear at every scale, from a single function to a distributed system. Recognising the pattern activates its associated tradeoffs and failure modes automatically.
| Code | Name | When you see it | Key constraints |
|---|---|---|---|
| T1 | Hashing | Key distribution, dedup, content addressing, sharding | AT5, FM6 |
| T2 | Trees | Hierarchical data, indexes, sorted access, file systems | AT2, FM3 |
| T3 | Graphs | Dependencies, relationships, networks, routing | AT3, FM2 |
| T4 | Queues | Async processing, buffering, backpressure, ordering | AT10, FM3 |
| T5 | Caching | Memoization, CDN, read-through, precomputed results | AT4, FM7 |
| T6 | Redundancy | Replication, backups, failover, multi-region | AT1, FM1 |
| T7 | State Machines | Lifecycle management, workflows, protocol state | AT9, FM4 |
| T8 | Divide & Conquer | Sharding, MapReduce, microservices, recursive decomposition | AT5, FM2 |
| T9 | Consensus | Leader election, distributed locks, quorum, coordination | AT1, FM12 |
| T10 | Encoding | Serialisation, schema evolution, API versioning, compression | AT3, FM8 |
| T11 | Feedback Loops | Rate limiting, circuit breakers, autoscaling, A/B testing | AT7, FM2 |
| T12 | Tradeoffs | Every decision is an optimisation under constraints | AT*, FM* |
T5 (Caching) immediately activates AT4 and FM7. T9 (Consensus) immediately activates AT1 and FM12. The pattern is a compressed pointer to the questions you must answer.
MM — Mental Models
Mental models are lenses for interpreting a system before designing it. They are not implementation patterns — they are ways of seeing.
| Code | Name | What it models |
|---|---|---|
| MM1 | Transformation | Input -> process -> output |
| MM2 | Search | Find items satisfying a predicate |
| MM3 | Optimisation | Minimise/maximise under constraints |
| MM4 | Flow | Resources moving through a network |
| MM5 | State | A system whose outputs depend on history |
| MM6 | Networks | Nodes + edges + emergent behaviour |
| MM7 | Feedback | Output fed back as input |
| MM8 | Concurrency | Multiple agents operating simultaneously |
| MM9 | Redundancy | Extra capacity for fault tolerance |
| MM10 | Layered Abstraction | Complex detail hidden behind a simpler interface |
| MM11 | Indirection | Decouple caller from callee via a level of reference |
| MM12 | Tradeoffs | Every design choice has a cost |
A load balancer is MM11 (Indirection) applied to traffic distribution, with MM9 (Redundancy) as the reason it exists. Naming both makes the design intent visible.
P — Engineering Principles
Properties that well-designed systems have. Absent principles predict specific failure modes.
| Code | Name | Rule | Absent -> |
|---|---|---|---|
| P1 | Abstraction | Hide irrelevant detail | FM8 (callers depend on internals) |
| P2 | Modularity | Independently replaceable units | FM2 (blast radius unlimited) |
| P3 | Composability | Small units combine | FM3 (monoliths grow unbounded) |
| P4 | Separation of Concerns | Each component owns one responsibility | FM4 (shared mutable state) |
| P5 | Idempotency | Same input -> same output, always | FM4 (duplicate retries corrupt data) |
| P6 | Reproducibility | Any environment gives same result | FM8 (works locally, breaks in prod) |
| P7 | Immutability | Never change data in place | FM9 (silent overwrites) |
| P8 | Locality | Keep data close to computation | FM5 (latency amplification) |
| P9 | Fault Tolerance | Failures degrade gracefully | FM1 (single failure kills the system) |
| P10 | Observability | The system explains itself | FM11 (cannot diagnose failures) |
| P11 | Consistency | Single source of truth | FM4 (split-brain data) |
| P12 | Security Boundaries | Trust is explicitly granted | FM10 (over-privileged access) |
| P13 | Fail Fast | Surface errors early | FM9 (bad state propagates silently) |
| P14 | Least Privilege | Grant only what the task requires | FM10 (breached credential has full access) |
| P15 | Measure & Adapt | Optimise based on data | FM11 (optimising the wrong thing) |
The absent-principle column is the useful half of this table. It turns a list of virtues into a diagnostic tool.
L — Engineering Laws
Constraints that cannot be negotiated away. They apply regardless of stack, language, or team size.
| Code | Name | The law |
|---|---|---|
| L1 | Amdahl's | Parallelism speedup bounded by the sequential fraction |
| L2 | Moore's | Transistor density doubles roughly every 2 years |
| L3 | CAP | Distributed system: choose 2 of Consistency, Availability, Partition-tolerance |
| L4 | Little's | L = lambda * W (queue depth = arrival rate x wait time) |
| L5 | Metcalfe's | Network value proportional to n^2 |
| L6 | Brooks's | Adding engineers to a late project makes it later |
| L7 | Hofstadter's | Always takes longer than expected, even accounting for this law |
| L8 | Parkinson's | Work expands to fill the time available |
| L9 | Goodhart's | When a measure becomes a target, it ceases to be a good measure |
| L10 | Conway's | Architecture mirrors the communication structure of the team |
| L11 | Gall's | Complex systems that work evolved from simple systems that worked |
| L12 | Postel's | Be conservative in what you send, liberal in what you accept |
| L13 | Leaky Abstractions | All non-trivial abstractions leak |
| L14 | Hyrum's | Any observable behaviour of an API will be depended upon |
| L15 | Pareto | 80% of effects come from 20% of causes |
| L16 | Linus's | With enough eyes, all bugs are shallow |
L10 (Conway's Law) is the most underused diagnostic. When an architecture looks wrong, check the team structure first. The architecture usually reflects it.
A — System Archetypes
Most production systems are one of six shapes, or a combination. Identifying the archetype reveals the likely tradeoffs and the infrastructure it requires before any code is written.
| Code | Name | Canonical shape | Core AT | Core FM |
|---|---|---|---|---|
| A1 | Search & Discovery | Index -> query -> rank -> return | AT2, AT4 | FM6, FM3 |
| A2 | Social & Communication | Users -> relationships -> feed -> notifications | AT1, AT10 | FM4, FM6 |
| A3 | Marketplace & Transaction | Buyers -> sellers -> matching -> payment -> fulfilment | AT1, AT9 | FM4, FM10 |
| A4 | Media Delivery | Ingest -> encode -> store -> stream | AT2, AT4 | FM3, FM5 |
| A5 | Data Intelligence | Collect -> store -> transform -> analyse -> serve | AT4, AT9 | FM9, FM11 |
| A6 | Platform & API | Core resources exposed as an extensible API | AT3, AT8 | FM8 |
YouTube is A4 + A1 + A2. Uber is A3 + A5. When you can name the archetypes in a system, you can name the tradeoffs before the first line of code is written.
IC — Infrastructure Components
Twenty-six standard building blocks. Each has a canonical role. Using one component for another role is a design smell worth naming.
| Code | Name | Role |
|---|---|---|
| IC1 | DNS | Domain -> IP; globally cached |
| IC2 | CDN | Edge-cached static assets; geo-distributed |
| IC3 | Load Balancer | Distribute traffic across instances |
| IC4 | API Gateway | Auth, rate-limit, routing at network edge |
| IC5 | Service Mesh | Sidecar: inter-service auth / observability / retries |
| IC6 | Rate Limiter | Token-bucket / sliding-window throttle |
| IC7 | Application Server | Stateless compute; business logic |
| IC8 | Background Worker | Async job runner (Celery, Sidekiq, BullMQ) |
| IC9 | Cache Server | In-memory KV store (Redis, Memcached) |
| IC10 | Synchronous RPC / REST | Request/response inter-service call |
| IC11 | Service Discovery | Registry of live instances (Consul, Kubernetes DNS) |
| IC12 | Relational DB (ACID) | Transactions, foreign keys, strong consistency |
| IC13 | Message Queue / Event Stream | Durable async messaging (Kafka, SQS, RabbitMQ) |
| IC14 | NoSQL Document Store | Schema-flexible JSON documents (MongoDB, DynamoDB) |
| IC15 | Key-Value Store | Simple get/set at scale (DynamoDB, etcd) |
| IC16 | Wide Column Store | Sparse table, high write throughput (Cassandra, BigTable) |
| IC17 | Object Storage | Blob store, infinite scale (S3, GCS) |
| IC18 | Search Index | Full-text + faceted search (Elasticsearch, Typesense) |
| IC19 | Vector Database | Embedding similarity search (Pinecone, pgvector) |
| IC20 | Batch Processor | Large-scale offline jobs (Spark, Hadoop, BigQuery) |
| IC21 | Stream Processor | Continuous real-time computation (Flink, Kafka Streams) |
| IC22 | Metrics System | Time-series telemetry (Prometheus, Datadog) |
| IC23 | Log Aggregator | Centralised log collection and search (ELK, Loki) |
| IC24 | Distributed Tracing | Request-flow across services (Jaeger, Zipkin, OTEL) |
| IC25 | Config Management | Centralised feature flags and env config (Vault, LaunchDarkly) |
| IC26 | Orchestrator / Scheduler | Workload placement and lifecycle (Kubernetes, Nomad) |
IC22, IC23, and IC24 are frequently missing in early architectures. Their absence is FM11. By the time it matters, it is too late to add them without significant rework.
The Engineer's Map — where the vocabulary comes from
The vocabulary above did not begin as a reference sheet. It began as a book.
The Reference Book (Book 0) of The Computing Series — The Engineer's Map — is the source from which every code is derived. Each framework has a dedicated chapter. Each chapter explains not just the definition but the reasoning: why this tradeoff recurs, what the historical systems got wrong, how the failure mode manifests at scale.
Reading the vocabulary table tells you what FM7 is. Reading the chapter on FM7 in the Engineer's Map tells you why the thundering herd is structurally inevitable whenever you cache at scale, what the 2012 Facebook memcache incident looked like from the inside, and what the mitigations cost in terms of AT4.
The codes are a compressed pointer. The book is the decompression.
This matters for AI tools as much as it does for engineers. An AI that has only the codes will apply them mechanically — flagging FM8 at every API boundary regardless of actual risk. An AI that has been trained on the full chapters applies the codes with judgment, understanding that FM8 is highest-risk at schema boundaries between teams with different deployment cycles, not at every internal function call. For most teams using AI tools today, injecting the vocabulary file into context gets 80% of the benefit immediately. Reading the book gets the other 20%.
The Engineer's Map is free to read in sample form at computingseries.com/books/ref. Five chapters are available without an account. The compression block at the end of each chapter is designed specifically as a recall anchor — the same compact format used in the vocabulary tables above.
Why it sticks in large organisations
The problem with most internal vocabulary is that it is invented locally. A team coins a term, it spreads within the team, and then breaks down at the boundary with the next team who coined a different term for the same concept.
The Computing Series vocabulary works across team boundaries because it is grounded in a published, citable source. When you say FM11 in a design review, you can point to a chapter that defines it, shows it in historical incidents, and explains the mitigations. The vocabulary has an external reference point that does not depend on organisational memory.
The second reason it sticks is bounded size. Nine frameworks, just over 100 codes total. A new engineer can cover the full vocabulary in a week of reading. Compare this to undocumented tribal knowledge that takes months to absorb and never fully transfers.
The third reason is that the codes are diagnostic, not descriptive. They do not describe what a system does. They identify what it risks. An engineer who can say "this is T5 + FM7" has already stated the problem and pointed at the solution space. That is a fundamentally different kind of vocabulary than one built around feature names or internal project codenames.
And for AI tools, this property matters most of all. AI generates possibilities. It does not own consequences. A vocabulary that identifies risks — not just patterns — keeps the engineer in the evaluator role and the AI in the generator role. That division is the correct one.
Download the full reference
The complete vocabulary — all nine frameworks, all codes, the decision block format, the seven architecture questions, and instructions for injecting it into AI tools — in a single ASCII-clean Markdown file with no special characters or formatting dependencies.
Download computing-series-vocabulary.md
Paste it into your AI tool's context window, add it to your team's
CLAUDE.md, drop it into.github/copilot-instructions.md, or print it as a desk reference. Plain Markdown, no dependencies, works everywhere.Licensed under Creative Commons Attribution 4.0 (CC BY 4.0) — free to use, share, adapt, and redistribute for any purpose, including commercial use. Attribution required: "The Computing Series -- computingseries.com".