@opengroundplan/core 0.1.1

package/catalog/architectures/multi-agent.yaml

@@ -0,0 +1,61 @@
+id: multi-agent
+name: Multi-Agent (Orchestrator-Worker)
+family: ai
+oneLine: >-
+  Multiple agents — LLMs autonomously using tools in a loop — working together, typically as a lead
+  agent coordinating specialized subagents that operate in parallel.
+
+bestFor:
+  - Heavy parallelization
+  - Information that exceeds single context windows
+  - Interfacing with numerous complex tools
+  - Breadth-first queries pursuing multiple independent directions
+  - Tasks whose value is high enough to pay for the increased performance
+
+avoidWhen:
+  - The domain requires all agents to share the same context
+  - There are many dependencies between agents
+  - There is limited true parallelism — most coding tasks involve fewer truly parallelizable subtasks than research does
+  - The task value does not justify the token multiplier
+  - Simpler workflow or single-agent solutions have not been exhausted first
+
+complexity: very-high
+teamSize: { min: 3, max: 50 }   # engine input — no primary source publishes a team size for this pattern
+
+# derived, not from Richards — AI application patterns are not in the worksheet.
+# Calibrated against Richards' scale. cost 1 mirrors microservices' $$$$$: Anthropic publishes
+# ~15x the tokens of a chat interaction, which is the same order of premium.
+scores:
+  maintainability: 2
+  testability: 1   # non-deterministic between runs even with identical prompts
+  deployability: 3
+  simplicity: 1
+  scalability: 4
+  elasticity: 4
+  responsiveness: 1   # lead agents execute subagents synchronously, creating information-flow bottlenecks
+  fault-tolerance: 2  # long-running state across many tool calls; minor failures compound
+  evolvability: 3
+  abstraction: 3
+  interoperability: 3
+  cost: 1
+
+stackFit:
+  typescript: excellent
+  python: excellent
+  dotnet: good
+  node: excellent
+  go: good
+  rust: workable
+  java: good
+  polyglot: good
+  # Rated on async/concurrency maturity and official SDK coverage; no source ranks languages here.
+
+overlay: multi-agent
+
+keyTradeoff: >-
+  Parallel subagents buy breadth and context headroom beyond a single window, at roughly an order of
+  magnitude more tokens and a system that is non-deterministic and correspondingly hard to evaluate.
+
+sources:
+  - https://www.anthropic.com/engineering/multi-agent-research-system
+  - https://www.anthropic.com/engineering/building-effective-agents

package/catalog/architectures/mvc-mvvm.yaml

@@ -0,0 +1,62 @@
+id: mvc-mvvm
+name: MVC / MVVM (Separated Presentation)
+family: application
+oneLine: >-
+  Separated Presentation — a clear division between domain objects modelling the real world and the
+  presentation objects on screen; MVVM adds a view model holding presentation state, connected to the
+  view by two-way binding.
+
+bestFor:
+  - Any UI where code-behind coupling raises the cost of UI changes and makes the logic hard to unit test
+  - Testing presentation logic without the UI — view model and model are testable with no view present
+  - Parallel designer and developer work on the same screen
+  - Redesigning the app UI without touching view model or model code
+  - Wrapping a risky legacy model, where the view model acts as an adapter and avoids major changes to model code
+
+avoidWhen:
+  - You expect the acronym to mean one thing — Fowler calls MVC one of the most misunderstood patterns around, with important differences between systems using the name
+  - The platform has no data-binding or change-notification story, which is what MVVM depends on entirely
+  - The screen is trivial enough that a view model per screen is pure plumbing
+  - You would reference view types from view models, which inverts the pattern's directionality rule
+
+complexity: low
+teamSize: { min: 1, max: 60 }   # engine input — no primary source publishes a team size for this style
+
+# derived, not from Richards — application-level styles are not columns in the worksheet.
+# Same calibration convention as clean.yaml: runtime rows stay at monolith values, cost stays $ (=5).
+# This is a presentation-layer pattern, so it moves testability without touching domain structure —
+# hence maintainability 3 rather than the 4 the core-isolating styles earn.
+scores:
+  maintainability: 3
+  testability: 4
+  deployability: 2
+  simplicity: 4
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 3
+  abstraction: 3
+  interoperability: 2
+  cost: 5
+
+stackFit:
+  typescript: excellent   # reactive UI frameworks map naturally onto the binding model
+  python: good            # server-side MVC is idiomatic (Django's MTV)
+  dotnet: excellent       # MAUI/XAML, INotifyPropertyChanged, MVVM Toolkit, ReactiveUI, Prism
+  node: good              # server-side MVC
+  go: awkward             # no meaningful MVVM tradition
+  rust: awkward
+  java: excellent         # Spring MVC server-side; JavaFX properties for MVVM
+  polyglot: n/a
+
+keyTradeoff: >-
+  Separating presentation from domain makes UI logic testable and redesignable, at the cost of
+  binding and notification plumbing and an extra class layer per screen.
+
+overlay: mvc-mvvm
+
+sources:
+  - https://martinfowler.com/eaaDev/uiArchs.html
+  - https://herbertograca.com/2017/08/17/mvc-and-its-variants/
+  - https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm

package/catalog/architectures/nextjs-colocation.yaml

@@ -0,0 +1,67 @@
+id: nextjs-colocation
+name: Next.js App Router Colocation
+family: frontend
+oneLine: >-
+  Organize by the route tree itself — colocate project files inside route segments (safe, because only
+  page.js/route.js output reaches the client), use private _folders to opt out of routing and
+  (route groups) to organize without touching the URL.
+
+bestFor:
+  - Teams wanting routing-driven structure with zero extra configuration
+  - Partitioning by site section, intent, or team without changing URLs, via route groups
+  - Sections needing genuinely different UI shells, via multiple root layouts per group
+  - Scoping a loading state to one route by wrapping it in a group — an officially documented recipe
+
+avoidWhen:
+  - Users navigate between different root layouts — that triggers a full page reload
+  - Two route groups would resolve to the same path, which is an error
+  - Domain structure matters more than URL structure; Next.js is deliberately unopinionated above the routing layer
+  - You want the framework to prescribe an architecture — components/ and lib/ in its examples carry no framework significance
+
+complexity: low
+teamSize: { min: 1, max: 40 }   # engine input — the Next.js docs publish no team-size guidance
+
+# derived, not from Richards — framework conventions are not in the worksheet.
+# Calibrated against Richards' scale. Simplicity is the standout: this is the framework default,
+# so it costs nothing to adopt and nothing to explain to a new hire.
+scores:
+  maintainability: 3
+  testability: 3
+  deployability: 3
+  simplicity: 5
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 2   # structure is tied to the URL tree, so re-routing means restructuring
+  abstraction: 1
+  interoperability: 2
+  cost: 5
+
+stackFit:
+  typescript: excellent
+  python: n/a
+  dotnet: n/a
+  node: excellent
+  go: n/a
+  rust: n/a
+  java: n/a
+  polyglot: n/a
+
+keyTradeoff: >-
+  Colocation gives near-zero-config locality tied to the URL tree, but because the framework is
+  deliberately unopinionated above routing, cross-cutting domain structure is entirely your team's
+  discipline to invent and enforce.
+
+# Guidance, not a layout — see `guidance` below. The engine enforces that every architecture
+# declares one or the other, so this is data rather than a comment nothing reads.
+guidance: >-
+  This is the Next.js App Router's own convention, and the nextjs-app base already ships it:
+  the route tree under app/, private folders prefixed with an underscore, and route groups in
+  parentheses. An overlay would rewrite the base's layout with a copy of itself. Selecting this
+  records that the team is organising by route rather than by technical layer, which is the
+  decision that matters; the structure is already on disk.
+
+sources:
+  - https://nextjs.org/docs/app/getting-started/project-structure
+  - https://nextjs.org/docs/app/api-reference/file-conventions/route-groups

package/catalog/architectures/onion.yaml

@@ -0,0 +1,60 @@
+id: onion
+name: Onion Architecture
+family: application
+oneLine: >-
+  Ports and Adapters plus internal layering — all code may depend on layers more central, none may
+  depend on layers further out, so all coupling points toward a self-contained domain model.
+
+bestFor:
+  - Long-lived business applications where controlling coupling is the primary concern
+  - Domain models that must stand alone, coupled only to themselves
+  - Systems where the persistence choice must not dictate the design — the database is external, not the centre
+  - Enterprise applications needing structure *inside* the business logic, not just a core-versus-infrastructure split
+
+avoidWhen:
+  - Traditional layering already solves your problem adequately; Palermo's case is built specifically against UI and business logic coupling to data access
+  - You do not have enough business logic to warrant internal DDD-style layering
+  - The app is small — the extra concentric layers are framed as an enterprise-application concern
+  - You want the lightest version of this idea, in which case Hexagonal is the smaller commitment
+
+complexity: high
+teamSize: { min: 3, max: 100 }   # engine input — no primary source publishes a team size for this style
+
+# derived, not from Richards — application-level styles are not columns in the worksheet.
+# Same calibration convention as clean.yaml: runtime rows stay at monolith values, cost stays $ (=5).
+# simplicity is 2, matching clean rather than hexagonal, because it explicitly adds internal layers
+# on top of the two-zone Ports and Adapters model.
+scores:
+  maintainability: 4
+  testability: 5
+  deployability: 2
+  simplicity: 2
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 4
+  abstraction: 5
+  interoperability: 3
+  cost: 5
+
+stackFit:
+  typescript: excellent
+  python: good
+  dotnet: excellent   # Palermo's original is .NET-framed and Microsoft links it as canonical
+  node: good
+  go: workable
+  rust: good
+  java: excellent
+  polyglot: awkward
+
+keyTradeoff: >-
+  Inverting all coupling toward a self-contained domain model buys long-term changeability at the cost
+  of interfaces in the core and implementations pushed to the rim.
+
+overlay: onion
+
+sources:
+  - https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
+  - https://herbertograca.com/2017/09/21/onion-architecture/
+  - https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures

package/catalog/architectures/pipes-and-filters.yaml

@@ -0,0 +1,59 @@
+id: pipes-and-filters
+name: Pipes and Filters
+family: system
+oneLine: >-
+  Decompose complex processing into a sequence of independent, stateless filters connected by pipes,
+  where each filter does one thing and knows only its input and output schema.
+
+bestFor:
+  - Media or document processing with genuinely reorderable steps (moderate, resize, watermark, strip EXIF, publish)
+  - ETL/ELT where lineage and per-stage retry matter
+  - Stream processing needing per-stage backpressure
+  - Any workload where one stage is dramatically more expensive and needs its own hardware profile
+
+avoidWhen:
+  - The interaction is request-response and must complete within the initial request — Microsoft calls this out as the most common misapplication
+  - Steps are not actually independent, or must commit as one transaction
+  - Each step needs so much context that every filter loads and persists state
+  - You cannot make filters idempotent and detect duplicates — both are non-negotiable, since a filter crashing after work but before ack will be re-run
+
+complexity: medium
+teamSize: { min: 3, max: 100 }
+
+# derived, not from Richards — no pipes-and-filters column exists in the worksheet.
+# Calibrated against Richards' scale. responsiveness is low by construction: this is the pattern
+# Microsoft explicitly says not to use inside a synchronous request.
+scores:
+  maintainability: 4
+  testability: 4
+  deployability: 4
+  simplicity: 3
+  scalability: 4
+  elasticity: 4
+  responsiveness: 2
+  fault-tolerance: 4
+  evolvability: 4
+  abstraction: 3
+  interoperability: 3
+  cost: 3
+
+stackFit:
+  typescript: good        # queue-triggered functions with almost no plumbing
+  python: excellent       # Airflow/Dagster/Prefect are Python-native; Beam for portable definitions
+  dotnet: good            # Microsoft's own reference impl is C# Functions; TPL Dataflow in-process
+  node: good
+  go: workable
+  rust: workable
+  java: excellent         # Kafka Streams, Flink, Beam
+  polyglot: good          # a standardized message schema is what makes filters language-agnostic
+
+keyTradeoff: >-
+  You gain modularity, reuse, and independent scaling, but every pipe is a new failure boundary —
+  you inherit idempotency, duplicate delivery, and partial-failure semantics a monolithic function
+  never had to consider.
+
+overlay: pipes-and-filters
+
+sources:
+  - https://learn.microsoft.com/en-us/azure/architecture/patterns/pipes-and-filters
+  - https://github.com/Azure-Samples/cloud-design-patterns/tree/main/pipes-and-filters

package/catalog/architectures/rag-hybrid.yaml

@@ -0,0 +1,62 @@
+id: rag-hybrid
+name: RAG with Hybrid Retrieval
+family: ai
+oneLine: >-
+  Combine pre-trained parametric memory with non-parametric retrieval, running keyword and vector
+  search in parallel and fusing the two result sets (typically by reciprocal rank fusion) before
+  generation.
+
+bestFor:
+  - Knowledge-intensive tasks where the model's parametric knowledge is insufficient
+  - Systems needing provenance for their answers and the ability to update world knowledge without retraining
+  - Mixed query types — vector search finds conceptually similar content with no keyword match; keyword search supplies precision
+  - Corpora full of exact-match tokens — product codes, specialized jargon, dates, people's names
+  - Fusing heterogeneous rankers cheaply; RRF requires no tuning and the relevance indicators need not be related
+
+avoidWhen:
+  - The task is generative or creative rather than knowledge-grounded — there is no retrieval target
+  - You need an explicit sort order; explicit sorts override relevance-ranked results
+  - You have only one retriever — rank fusion needs at least two
+  - You depend on features rank fusion breaks — scroll, sort, rescore, and highlighting over vector fields
+
+complexity: high
+teamSize: { min: 2, max: 50 }   # engine input — no primary source publishes a team size for this pattern
+
+# derived, not from Richards — AI application patterns are not in the worksheet.
+# Calibrated against Richards' scale. Two indexes to build, tune, and keep in sync is the
+# dominant maintenance cost, and query fan-out is multiplicative.
+scores:
+  maintainability: 3
+  testability: 3
+  deployability: 3
+  simplicity: 2
+  scalability: 4
+  elasticity: 3
+  responsiveness: 3
+  fault-tolerance: 3
+  evolvability: 4   # updating the corpus updates the system, with no retraining
+  abstraction: 3
+  interoperability: 4
+  cost: 3
+
+stackFit:
+  typescript: good
+  python: excellent   # the center of gravity for embedding and evaluation tooling
+  dotnet: good
+  node: good
+  go: workable        # REST clients exist; first-party coverage is thinner
+  rust: workable
+  java: good
+  polyglot: good      # every major engine exposes REST
+
+keyTradeoff: >-
+  Fusing two retrievers reliably improves recall across query types, but the fused score becomes
+  uninterpretable as a relevance magnitude and you inherit two indexes to build, tune, and keep in sync.
+
+overlay: rag-hybrid
+
+sources:
+  - https://arxiv.org/abs/2005.11401
+  - https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
+  - https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
+  - https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion

package/catalog/architectures/serverless.yaml

@@ -0,0 +1,58 @@
+id: serverless
+name: Serverless / FaaS
+family: system
+oneLine: >-
+  Deploy individual event-triggered functions to a platform that provisions, scales, and bills per
+  invocation, so you never manage a server or an idle instance.
+
+bestFor:
+  - Spiky or near-zero-baseline traffic — webhooks, scheduled jobs, internal tools
+  - Event glue — object-storage triggers, queue consumers, CDC fan-out
+  - Small teams with no platform engineer
+  - Bursty batch fan-out
+
+avoidWhen:
+  - Sustained high utilization — provisioned compute wins somewhere around 60-80% sustained utilization
+  - Long-running or stateful work; the 15-minute ceiling is the second, harder cliff
+  - Hard p99 requirements where cold starts are unacceptable and provisioned concurrency erases the cost case
+  - You are not willing to make IaC a hard requirement; clicking through a console does not scale to dozens of functions
+
+complexity: medium
+teamSize: { min: 1, max: 30 }
+
+# derived, not from Richards — no serverless column exists in the worksheet.
+# Calibrated against Richards' scale. Note cost is genuinely bimodal: 4 at low/spiky utilization,
+# closer to 1 above ~60-80% sustained utilization, which is the documented cliff.
+scores:
+  maintainability: 3
+  testability: 2
+  deployability: 5
+  simplicity: 3
+  scalability: 5
+  elasticity: 5
+  responsiveness: 2
+  fault-tolerance: 4
+  evolvability: 4
+  abstraction: 3
+  interoperability: 3
+  cost: 4
+
+stackFit:
+  typescript: excellent   # SST is a generation ahead on DX; SAM and CDK are the free vendor-native options
+  python: excellent       # fast cold starts, dominant for data/ML glue
+  dotnet: good            # Azure Functions isolated worker; on AWS, SnapStart + Native AOT closes most of the gap
+  node: excellent
+  go: good
+  rust: good
+  java: workable          # SnapStart is GA and helps, but init weight is still the constraint
+  polyglot: good
+
+keyTradeoff: >-
+  You trade operational cost for architectural constraint — no servers, but your app must be
+  stateless, short-lived, and event-shaped, and if it is steadily busy you pay a large premium.
+
+overlay: serverless
+
+sources:
+  - https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
+  - https://docs.aws.amazon.com/decision-guides/latest/fargate-or-lambda/fargate-or-lambda.html

package/catalog/architectures/vertical-slice.yaml

@@ -0,0 +1,61 @@
+id: vertical-slice
+name: Vertical Slice Architecture
+family: application
+oneLine: >-
+  Build around distinct requests, encapsulating and grouping all concerns from front-end to back —
+  coupling along the axis of change, minimizing coupling between slices and maximizing it within one.
+
+bestFor:
+  - Request-shaped systems where each feature has genuinely different needs
+  - Teams that want abstractions earned rather than imposed — start with a transaction script and refactor to the patterns the code smells demand
+  - Codebases where shared layer abstractions are pure overhead; no shared repositories, services, or controller layers
+  - Large systems needing top-level decomposition by feature, which Fowler independently recommends
+  - Mixed complexity per feature — procedural handlers for CRUD, behaviour pushed into domain objects only where warranted
+
+avoidWhen:
+  - The team cannot reliably spot refactoring opportunities; Bogard says explicitly it is likely not for you
+  - You depend on uniform structural guardrails — the whole move is removing the gates and barriers across layers
+  - Weak code accumulating inside a slice would go unnoticed for long
+  - You expect it to sit alongside a layered core; Bogard positions it as a replacement, not a complement
+
+complexity: medium
+teamSize: { min: 2, max: 60 }   # engine input — Bogard gates on team *skill*, not size, and states no range
+
+# derived, not from Richards — application-level styles are not columns in the worksheet.
+# Same calibration convention as clean.yaml: runtime rows stay at monolith values, cost stays $ (=5).
+# abstraction is deliberately low: removing shared layer abstractions is the explicit intent, so a
+# low score here is the style working as designed, not a defect.
+scores:
+  maintainability: 4
+  testability: 4
+  deployability: 2
+  simplicity: 4
+  scalability: 1
+  elasticity: 1
+  responsiveness: 3
+  fault-tolerance: 1
+  evolvability: 5   # coupling along the axis of change is the entire claim
+  abstraction: 2
+  interoperability: 2
+  cost: 5
+
+stackFit:
+  typescript: excellent
+  python: good        # per-feature folders are already idiomatic
+  dotnet: excellent   # the pattern grew here; MediatR is Bogard's own
+  node: excellent
+  go: good            # resists deep abstraction hierarchies anyway
+  rust: good
+  java: good
+  polyglot: awkward
+
+keyTradeoff: >-
+  Per-feature freedom and high cohesion, bought by giving up the uniform structural constraints that
+  stop weaker code from accumulating inside a slice.
+
+overlay: vertical-slice
+
+sources:
+  - https://www.jimmybogard.com/vertical-slice-architecture/
+  - https://www.jimmybogard.com/domain-command-patterns-handlers/
+  - https://martinfowler.com/bliki/PresentationDomainDataLayering.html

package/catalog/characteristics.yaml

@@ -0,0 +1,165 @@
+# The 12 axes every architecture entry scores on. Keys must match the Characteristic enum in
+# packages/core/src/schema.ts exactly — the decision engine ranks by sum(weight * score).
+#
+# SCALE: 1-5, and HIGHER IS ALWAYS BETTER. This matters for `cost`, which Richards publishes as a
+# $ row where more $ is worse; it is inverted here ($=5 … $$$$$=1) so one ranking formula works.
+#
+# PROVENANCE: Richards' Architecture Characteristics Worksheet defines 18 "common" characteristics
+# plus four "implicit" ones. Only 8 of our 12 appear there with a definition we can quote. The other
+# 4 are scored rows in the *styles* worksheet that the *characteristics* worksheet never defines.
+# Each entry below declares `verbatim: true|false` — do not promote a paraphrase to a quotation.
+
+scale:
+  min: 1
+  max: 5
+  direction: higher-is-better
+  costInversion: "Richards' $ row mapped $=5, $$=4, $$$=3, $$$$=2, $$$$$=1."
+
+# Worksheet rules that constrain how these are used, quoted from Richards' own instructions.
+selectionRules:
+  - "Identify no more than 7 driving characteristics."
+  - "Pick the top 3 characteristics (in any order)."
+  - "Implicit characteristics can become driving characteristics if they are critical concerns."
+  # Richards' position: architects consistently over-select; a system optimized for everything is
+  # optimized for nothing. Step 3 of the procedure makes a single 1 disqualifying, not averaged away.
+  - "Discard any style scoring 1 on any of your top 3 — a single 1 is disqualifying."
+
+# Composites must be decomposed before scoring, never rated directly.
+composites:
+  agility: [maintainability, testability, deployability]
+  reliability: [fault-tolerance, testability]   # full worksheet list also spans availability + data integrity/consistency, which are not scored rows here
+
+characteristics:
+  - id: maintainability
+    verbatim: false
+    note: >-
+      Classified implicit in the characteristics worksheet, so it carries no published definition
+      there, yet it is a scored row in the styles worksheet. Wording below is ours.
+    definition: >-
+      The ease with which the system can be changed and enhanced without disproportionate
+      collateral edits.
+    strong: [clean, hexagonal, onion, vertical-slice, ddd-tactical, feature-sliced-design,
+             microservices, cqrs, bff, pipes-and-filters, llm-workflow, medallion]
+    weak: [layered, modular-monolith, monolith, multi-agent]
+
+  - id: testability
+    verbatim: true
+    definition: "The ease of and completeness of testing"
+    strong: [clean, hexagonal, onion, vertical-slice, ddd-tactical, mvc-mvvm, feature-sliced-design,
+             microservices, cqrs, pipes-and-filters, llm-workflow, medallion]
+    weak: [layered, modular-monolith, monolith, event-driven, serverless, micro-frontends,
+           agentic-tool-loop, multi-agent]
+
+  - id: deployability
+    verbatim: true
+    definition: >-
+      The amount of ceremony involved with releasing the software, the frequency in which releases
+      occur, and the overall risk of deployment
+    strong: [microservices, serverless, micro-frontends, bff, pipes-and-filters, llm-workflow,
+             agentic-tool-loop]
+    weak: [layered, modular-monolith, monolith, clean, hexagonal, onion, vertical-slice,
+           ddd-tactical, mvc-mvvm, feature-sliced-design, cqrs]
+
+  - id: simplicity
+    verbatim: false
+    note: >-
+      A scored row in the styles worksheet with no definition in the characteristics worksheet.
+      Wording below is ours.
+    definition: >-
+      How little a competent engineer must hold in their head to change the system safely.
+    strong: [layered, modular-monolith, monolith, vertical-slice, mvc-mvvm, nextjs-colocation,
+             llm-workflow]
+    weak: [clean, onion, ddd-tactical, feature-sliced-design, microservices, event-driven,
+           micro-frontends, rag-hybrid, multi-agent, lakehouse]
+
+  - id: scalability
+    verbatim: true
+    definition: >-
+      A function of system capacity and growth over time; as the number of users or requests
+      increase, responsiveness, performance, and error rates remain constant
+    strong: [microservices, event-driven, cqrs, serverless, pipes-and-filters, llm-workflow,
+             rag-hybrid, multi-agent, medallion, lakehouse]
+    weak: [layered, modular-monolith, monolith, clean, hexagonal, onion, vertical-slice,
+           ddd-tactical, mvc-mvvm, feature-sliced-design, nextjs-colocation]
+
+  - id: elasticity
+    verbatim: true
+    definition: >-
+      The system is able to expand and respond quickly to unexpected or anticipated extreme loads
+      (e.g., going from 20 to 250,000 users instantly)
+    strong: [microservices, serverless, pipes-and-filters, llm-workflow, agentic-tool-loop,
+             multi-agent, medallion, lakehouse]
+    weak: [layered, modular-monolith, monolith, clean, hexagonal, onion, vertical-slice,
+           ddd-tactical, mvc-mvvm, feature-sliced-design, nextjs-colocation]
+
+  - id: responsiveness
+    verbatim: true
+    definition: "The amount of time it takes to get a response to the user"
+    # The row that inverts the microservices story: event-driven scores 5, microservices 2.
+    strong: [event-driven, cqrs, bff]
+    weak: [microservices, serverless, micro-frontends, pipes-and-filters, agentic-tool-loop,
+           multi-agent, medallion]
+
+  - id: fault-tolerance
+    verbatim: true
+    definition: "When fatal errors occur, other parts of the system continue to function"
+    strong: [microservices, event-driven, serverless, pipes-and-filters, medallion, lakehouse]
+    weak: [layered, modular-monolith, monolith, clean, hexagonal, onion, vertical-slice,
+           ddd-tactical, mvc-mvvm, feature-sliced-design, nextjs-colocation, cqrs, bff,
+           agentic-tool-loop, multi-agent]
+
+  - id: evolvability
+    verbatim: false
+    note: >-
+      A scored row in the styles worksheet with no definition in the characteristics worksheet. The
+      nearest defined pair there is adaptability ("The ease in which a system can adapt to changes in
+      environment and functionality") and extensibility ("The ease in which a system can be extended
+      with additional features"). Wording below is ours.
+    definition: >-
+      The ease with which the system's structure itself can change as the business changes, not just
+      its behaviour.
+    strong: [clean, hexagonal, onion, vertical-slice, ddd-tactical, feature-sliced-design,
+             microservices, event-driven, cqrs, serverless, micro-frontends, bff,
+             pipes-and-filters, agentic-tool-loop, rag-hybrid, medallion, lakehouse]
+    weak: [layered, modular-monolith, monolith, nextjs-colocation]
+
+  - id: abstraction
+    verbatim: true
+    definition: "The level at which parts of the system are isolated from other parts"
+    # Note microservices scores 1 here — services know each other's contracts directly.
+    strong: [clean, hexagonal, onion, ddd-tactical, feature-sliced-design, event-driven, medallion]
+    weak: [layered, modular-monolith, monolith, vertical-slice, nextjs-colocation, microservices,
+           micro-frontends, lakehouse]
+
+  - id: interoperability
+    verbatim: true
+    definition: "The ability of the system to interface and interact with other systems"
+    strong: [hexagonal, bff, agentic-tool-loop, rag-hybrid, lakehouse]
+    weak: [layered, modular-monolith, monolith, vertical-slice, ddd-tactical, mvc-mvvm,
+           feature-sliced-design, nextjs-colocation, cqrs]
+
+  - id: cost
+    verbatim: false
+    note: >-
+      Classified implicit as "feasibility (cost/time)" in the characteristics worksheet, with no
+      quotable definition; the styles worksheet carries it as a $ row instead. Inverted here so
+      higher is cheaper. Wording below is ours.
+    definition: >-
+      Infrastructure and operational spend the style obliges you to carry. Modelling and engineering
+      effort is not counted here — that signal lives in `simplicity` and in each entry's `complexity`.
+    strong: [layered, modular-monolith, monolith, clean, hexagonal, onion, vertical-slice,
+             ddd-tactical, mvc-mvvm, feature-sliced-design, nextjs-colocation, serverless, bff,
+             llm-workflow, lakehouse]
+    weak: [microservices, micro-frontends, agentic-tool-loop, multi-agent]
+
+# Present in Richards' worksheet, deliberately NOT scored here. Availability decomposes into
+# fault-tolerance + recoverability; security and observability are implicit and should be
+# always-on scaffolding defaults, never selection inputs. Do not invent ratings for them.
+notScored: [performance, availability, data-integrity, data-consistency, adaptability,
+            extensibility, concurrency, workflow, configurability, recoverability, security,
+            observability]
+
+sources:
+  - https://www.developertoarchitect.com/downloads/architecture-characteristics-worksheet.pdf
+  - https://www.developertoarchitect.com/downloads/architecture-styles-worksheet.pdf
+  - https://developertoarchitect.com/resources.html