# Architecture principles

> 477 records

This index as JSON: https://banes-lab.com/json/api/records/architecture

## Fields

- `type`: [activity](https://banes-lab.com/api/facets/architecture/type/activity.md) (25), [anti-pattern](https://banes-lab.com/api/facets/architecture/type/anti-pattern.md) (85), [approach](https://banes-lab.com/api/facets/architecture/type/approach.md) (9), [artifact](https://banes-lab.com/api/facets/architecture/type/artifact.md) (9), [capability](https://banes-lab.com/api/facets/architecture/type/capability.md) (5), [constraint](https://banes-lab.com/api/facets/architecture/type/constraint.md) (37), [mechanism](https://banes-lab.com/api/facets/architecture/type/mechanism.md) (74), [metric](https://banes-lab.com/api/facets/architecture/type/metric.md) (5), [model](https://banes-lab.com/api/facets/architecture/type/model.md) (18), [pattern](https://banes-lab.com/api/facets/architecture/type/pattern.md) (69), [principle](https://banes-lab.com/api/facets/architecture/type/principle.md) (81), [quality-attribute](https://banes-lab.com/api/facets/architecture/type/quality-attribute.md) (29), [style](https://banes-lab.com/api/facets/architecture/type/style.md) (16), [technique](https://banes-lab.com/api/facets/architecture/type/technique.md) (15)
- `category`: [anti-patterns](https://banes-lab.com/api/facets/architecture/category/anti-patterns.md) (78), [Architecture Review / Evolution / Governance Artifacts](https://banes-lab.com/api/facets/architecture/category/architecture-review-evolution-governance-artifacts.md) (17), [Behavioral Patterns](https://banes-lab.com/api/facets/architecture/category/behavioral-patterns.md) (13), [Causality / Ordering / Distributed Time](https://banes-lab.com/api/facets/architecture/category/causality-ordering-distributed-time.md) (14), [Codebase / System Architecture Styles](https://banes-lab.com/api/facets/architecture/category/codebase-system-architecture-styles.md) (11), [Contracts / Interfaces / Compatibility](https://banes-lab.com/api/facets/architecture/category/contracts-interfaces-compatibility.md) (20), [Control / Coordination / Centralization](https://banes-lab.com/api/facets/architecture/category/control-coordination-centralization.md) (9), [Coordination Surfaces](https://banes-lab.com/api/facets/architecture/category/coordination-surfaces.md) (28), [Core Modular Design](https://banes-lab.com/api/facets/architecture/category/core-modular-design.md) (16), [Correctness / Determinism / Verification](https://banes-lab.com/api/facets/architecture/category/correctness-determinism-verification.md) (15), [Creational Patterns](https://banes-lab.com/api/facets/architecture/category/creational-patterns.md) (6), [Domain Architecture](https://banes-lab.com/api/facets/architecture/category/domain-architecture.md) (10), [Error Handling / Resilience](https://banes-lab.com/api/facets/architecture/category/error-handling-resilience.md) (16), [Event / Messaging / Asynchronous Architecture](https://banes-lab.com/api/facets/architecture/category/event-messaging-asynchronous-architecture.md) (19), [Metadata / Self-Description / Declarative Systems](https://banes-lab.com/api/facets/architecture/category/metadata-self-description-declarative-systems.md) (8), [Metaprogramming / Language-Oriented Architecture](https://banes-lab.com/api/facets/architecture/category/metaprogramming-language-oriented-architecture.md) (10), [Model Architecture](https://banes-lab.com/api/facets/architecture/category/model-architecture.md) (13), [Observability / Auditability / Traceability](https://banes-lab.com/api/facets/architecture/category/observability-auditability-traceability.md) (12), [Plugin / Extensibility / IoC](https://banes-lab.com/api/facets/architecture/category/plugin-extensibility-ioc.md) (8), [Portability / Infrastructure / Deployment](https://banes-lab.com/api/facets/architecture/category/portability-infrastructure-deployment.md) (9), [Runtime Discovery / Dynamic Binding](https://banes-lab.com/api/facets/architecture/category/runtime-discovery-dynamic-binding.md) (5), [Scalability / Performance / Optimization](https://banes-lab.com/api/facets/architecture/category/scalability-performance-optimization.md) (28), [Schema / Canonical Data / Semantics](https://banes-lab.com/api/facets/architecture/category/schema-canonical-data-semantics.md) (13), [Security / Privacy / Compliance / Governance](https://banes-lab.com/api/facets/architecture/category/security-privacy-compliance-governance.md) (27), [Self-Healing / Recovery / Deployment Safety](https://banes-lab.com/api/facets/architecture/category/self-healing-recovery-deployment-safety.md) (13), [SOLID / Object-Oriented Design](https://banes-lab.com/api/facets/architecture/category/solid-object-oriented-design.md) (5), [Streaming / Pipeline / Dataflow Processing](https://banes-lab.com/api/facets/architecture/category/streaming-pipeline-dataflow-processing.md) (11), [Structural Patterns](https://banes-lab.com/api/facets/architecture/category/structural-patterns.md) (7), [Taxonomy / Classification / Naming](https://banes-lab.com/api/facets/architecture/category/taxonomy-classification-naming.md) (23), [Transactions / State / Concurrency](https://banes-lab.com/api/facets/architecture/category/transactions-state-concurrency.md) (13)
- `severity`: [contextual](https://banes-lab.com/api/facets/architecture/severity/contextual.md) (191), [discouraged](https://banes-lab.com/api/facets/architecture/severity/discouraged.md) (88), [mandatory](https://banes-lab.com/api/facets/architecture/severity/mandatory.md) (102), [recommended](https://banes-lab.com/api/facets/architecture/severity/recommended.md) (96)
- `scope`: [absence](https://banes-lab.com/api/facets/architecture/scope/absence.md) (1), [abstraction](https://banes-lab.com/api/facets/architecture/scope/abstraction.md) (1), [access](https://banes-lab.com/api/facets/architecture/scope/access.md) (1), [access control](https://banes-lab.com/api/facets/architecture/scope/access-control.md) (1), [aggregate](https://banes-lab.com/api/facets/architecture/scope/aggregate.md) (2), [aggregation](https://banes-lab.com/api/facets/architecture/scope/aggregation.md) (1), [agreement](https://banes-lab.com/api/facets/architecture/scope/agreement.md) (1), [algorithm](https://banes-lab.com/api/facets/architecture/scope/algorithm.md) (11), [allocation](https://banes-lab.com/api/facets/architecture/scope/allocation.md) (2), [API](https://banes-lab.com/api/facets/architecture/scope/api.md) (38), [application](https://banes-lab.com/api/facets/architecture/scope/application.md) (20), [application service](https://banes-lab.com/api/facets/architecture/scope/application-service.md) (1), [application structure](https://banes-lab.com/api/facets/architecture/scope/application-structure.md) (1), [architecture](https://banes-lab.com/api/facets/architecture/scope/architecture.md) (8), [architecture decision](https://banes-lab.com/api/facets/architecture/scope/architecture-decision.md) (1), [architecture_evolution](https://banes-lab.com/api/facets/architecture/scope/architecture-evolution.md) (11), [async processing](https://banes-lab.com/api/facets/architecture/scope/async-processing.md) (1), [audit](https://banes-lab.com/api/facets/architecture/scope/audit.md) (1), [auth](https://banes-lab.com/api/facets/architecture/scope/auth.md) (1), [authentication](https://banes-lab.com/api/facets/architecture/scope/authentication.md) (1), [authorship](https://banes-lab.com/api/facets/architecture/scope/authorship.md) (1), [availability](https://banes-lab.com/api/facets/architecture/scope/availability.md) (2), [backups](https://banes-lab.com/api/facets/architecture/scope/backups.md) (1), [behavior](https://banes-lab.com/api/facets/architecture/scope/behavior.md) (12), [behavior composition](https://banes-lab.com/api/facets/architecture/scope/behavior-composition.md) (1), [boundary](https://banes-lab.com/api/facets/architecture/scope/boundary.md) (4), [bounded context](https://banes-lab.com/api/facets/architecture/scope/bounded-context.md) (6), [bounded context boundary](https://banes-lab.com/api/facets/architecture/scope/bounded-context-boundary.md) (1), [bounded contexts](https://banes-lab.com/api/facets/architecture/scope/bounded-contexts.md) (1), [build](https://banes-lab.com/api/facets/architecture/scope/build.md) (7), [cache](https://banes-lab.com/api/facets/architecture/scope/cache.md) (1), [capability](https://banes-lab.com/api/facets/architecture/scope/capability.md) (1), [capacity](https://banes-lab.com/api/facets/architecture/scope/capacity.md) (1), [causality_ordering](https://banes-lab.com/api/facets/architecture/scope/causality-ordering.md) (2), [change](https://banes-lab.com/api/facets/architecture/scope/change.md) (2), [channel](https://banes-lab.com/api/facets/architecture/scope/channel.md) (1), [check](https://banes-lab.com/api/facets/architecture/scope/check.md) (1), [CI/CD](https://banes-lab.com/api/facets/architecture/scope/ci-cd.md) (1), [class](https://banes-lab.com/api/facets/architecture/scope/class.md) (14), [class hierarchy](https://banes-lab.com/api/facets/architecture/scope/class-hierarchy.md) (1), [code](https://banes-lab.com/api/facets/architecture/scope/code.md) (2), [code change](https://banes-lab.com/api/facets/architecture/scope/code-change.md) (1), [code generation](https://banes-lab.com/api/facets/architecture/scope/code-generation.md) (2), [code path](https://banes-lab.com/api/facets/architecture/scope/code-path.md) (2), [codebase](https://banes-lab.com/api/facets/architecture/scope/codebase.md) (13), [collection](https://banes-lab.com/api/facets/architecture/scope/collection.md) (2), [command](https://banes-lab.com/api/facets/architecture/scope/command.md) (1), [compile-time](https://banes-lab.com/api/facets/architecture/scope/compile-time.md) (1), [compiler](https://banes-lab.com/api/facets/architecture/scope/compiler.md) (2), [compliance](https://banes-lab.com/api/facets/architecture/scope/compliance.md) (2), [component](https://banes-lab.com/api/facets/architecture/scope/component.md) (24), [composition](https://banes-lab.com/api/facets/architecture/scope/composition.md) (1), [composition root](https://banes-lab.com/api/facets/architecture/scope/composition-root.md) (1), [computation](https://banes-lab.com/api/facets/architecture/scope/computation.md) (2), [concurrency](https://banes-lab.com/api/facets/architecture/scope/concurrency.md) (6), [config](https://banes-lab.com/api/facets/architecture/scope/config.md) (1), [configuration](https://banes-lab.com/api/facets/architecture/scope/configuration.md) (5), [consistency](https://banes-lab.com/api/facets/architecture/scope/consistency.md) (3), [consistency boundary](https://banes-lab.com/api/facets/architecture/scope/consistency-boundary.md) (1), [consumer](https://banes-lab.com/api/facets/architecture/scope/consumer.md) (1), [context](https://banes-lab.com/api/facets/architecture/scope/context.md) (2), [contract_compatibility](https://banes-lab.com/api/facets/architecture/scope/contract-compatibility.md) (20), [control flow](https://banes-lab.com/api/facets/architecture/scope/control-flow.md) (1), [control_coordination](https://banes-lab.com/api/facets/architecture/scope/control-coordination.md) (5), [convergence](https://banes-lab.com/api/facets/architecture/scope/convergence.md) (1), [coordination](https://banes-lab.com/api/facets/architecture/scope/coordination.md) (6), [correctness](https://banes-lab.com/api/facets/architecture/scope/correctness.md) (1), [correctness_verification](https://banes-lab.com/api/facets/architecture/scope/correctness-verification.md) (15), [CPU](https://banes-lab.com/api/facets/architecture/scope/cpu.md) (1), [critical section](https://banes-lab.com/api/facets/architecture/scope/critical-section.md) (1), [critical system](https://banes-lab.com/api/facets/architecture/scope/critical-system.md) (1), [data](https://banes-lab.com/api/facets/architecture/scope/data.md) (25), [data access](https://banes-lab.com/api/facets/architecture/scope/data-access.md) (3), [data model](https://banes-lab.com/api/facets/architecture/scope/data-model.md) (1), [data modeling](https://banes-lab.com/api/facets/architecture/scope/data-modeling.md) (1), [data mutation](https://banes-lab.com/api/facets/architecture/scope/data-mutation.md) (1), [data processing](https://banes-lab.com/api/facets/architecture/scope/data-processing.md) (5), [data structure](https://banes-lab.com/api/facets/architecture/scope/data-structure.md) (1), [database](https://banes-lab.com/api/facets/architecture/scope/database.md) (9), [dataflow](https://banes-lab.com/api/facets/architecture/scope/dataflow.md) (1), [decision flow](https://banes-lab.com/api/facets/architecture/scope/decision-flow.md) (2), [default](https://banes-lab.com/api/facets/architecture/scope/default.md) (1), [delivery](https://banes-lab.com/api/facets/architecture/scope/delivery.md) (1), [dependency access](https://banes-lab.com/api/facets/architecture/scope/dependency-access.md) (1), [dependency call](https://banes-lab.com/api/facets/architecture/scope/dependency-call.md) (3), [dependency graph](https://banes-lab.com/api/facets/architecture/scope/dependency-graph.md) (2), [deployment](https://banes-lab.com/api/facets/architecture/scope/deployment.md) (19), [derivation](https://banes-lab.com/api/facets/architecture/scope/derivation.md) (1), [design change](https://banes-lab.com/api/facets/architecture/scope/design-change.md) (1), [dev](https://banes-lab.com/api/facets/architecture/scope/dev.md) (1), [directory](https://banes-lab.com/api/facets/architecture/scope/directory.md) (1), [distributed data](https://banes-lab.com/api/facets/architecture/scope/distributed-data.md) (1), [distributed events](https://banes-lab.com/api/facets/architecture/scope/distributed-events.md) (3), [distributed state](https://banes-lab.com/api/facets/architecture/scope/distributed-state.md) (7), [distributed system](https://banes-lab.com/api/facets/architecture/scope/distributed-system.md) (9), [distributed transaction](https://banes-lab.com/api/facets/architecture/scope/distributed-transaction.md) (1), [domain](https://banes-lab.com/api/facets/architecture/scope/domain.md) (18), [domain action](https://banes-lab.com/api/facets/architecture/scope/domain-action.md) (1), [domain invariant](https://banes-lab.com/api/facets/architecture/scope/domain-invariant.md) (1), [domain logic](https://banes-lab.com/api/facets/architecture/scope/domain-logic.md) (1), [domain model](https://banes-lab.com/api/facets/architecture/scope/domain-model.md) (1), [domain_boundary](https://banes-lab.com/api/facets/architecture/scope/domain-boundary.md) (11), [duplicate](https://banes-lab.com/api/facets/architecture/scope/duplicate.md) (2), [early product](https://banes-lab.com/api/facets/architecture/scope/early-product.md) (1), [enterprise data](https://banes-lab.com/api/facets/architecture/scope/enterprise-data.md) (1), [entity](https://banes-lab.com/api/facets/architecture/scope/entity.md) (1), [event](https://banes-lab.com/api/facets/architecture/scope/event.md) (6), [event notification](https://banes-lab.com/api/facets/architecture/scope/event-notification.md) (1), [event store](https://banes-lab.com/api/facets/architecture/scope/event-store.md) (1), [event_messaging](https://banes-lab.com/api/facets/architecture/scope/event-messaging.md) (5), [eventing](https://banes-lab.com/api/facets/architecture/scope/eventing.md) (1), [events](https://banes-lab.com/api/facets/architecture/scope/events.md) (1), [expression](https://banes-lab.com/api/facets/architecture/scope/expression.md) (1), [feature](https://banes-lab.com/api/facets/architecture/scope/feature.md) (2), [field](https://banes-lab.com/api/facets/architecture/scope/field.md) (2), [file](https://banes-lab.com/api/facets/architecture/scope/file.md) (7), [filename](https://banes-lab.com/api/facets/architecture/scope/filename.md) (10), [folder](https://banes-lab.com/api/facets/architecture/scope/folder.md) (7), [framework](https://banes-lab.com/api/facets/architecture/scope/framework.md) (9), [function](https://banes-lab.com/api/facets/architecture/scope/function.md) (21), [greenfield](https://banes-lab.com/api/facets/architecture/scope/greenfield.md) (1), [handler](https://banes-lab.com/api/facets/architecture/scope/handler.md) (1), [hierarchy](https://banes-lab.com/api/facets/architecture/scope/hierarchy.md) (2), [history](https://banes-lab.com/api/facets/architecture/scope/history.md) (1), [identity](https://banes-lab.com/api/facets/architecture/scope/identity.md) (4), [immutability](https://banes-lab.com/api/facets/architecture/scope/immutability.md) (1), [implementation](https://banes-lab.com/api/facets/architecture/scope/implementation.md) (1), [implementation variation](https://banes-lab.com/api/facets/architecture/scope/implementation-variation.md) (1), [index](https://banes-lab.com/api/facets/architecture/scope/index.md) (2), [infrastructure](https://banes-lab.com/api/facets/architecture/scope/infrastructure.md) (28), [input](https://banes-lab.com/api/facets/architecture/scope/input.md) (3), [input processing](https://banes-lab.com/api/facets/architecture/scope/input-processing.md) (1), [integration](https://banes-lab.com/api/facets/architecture/scope/integration.md) (21), [integrity](https://banes-lab.com/api/facets/architecture/scope/integrity.md) (1), [interface](https://banes-lab.com/api/facets/architecture/scope/interface.md) (5), [invariant boundary](https://banes-lab.com/api/facets/architecture/scope/invariant-boundary.md) (1), [invocation](https://banes-lab.com/api/facets/architecture/scope/invocation.md) (3), [IO](https://banes-lab.com/api/facets/architecture/scope/io.md) (3), [iterator](https://banes-lab.com/api/facets/architecture/scope/iterator.md) (2), [knowledge modeling](https://banes-lab.com/api/facets/architecture/scope/knowledge-modeling.md) (1), [knowledge retrieval](https://banes-lab.com/api/facets/architecture/scope/knowledge-retrieval.md) (1), [language](https://banes-lab.com/api/facets/architecture/scope/language.md) (2), [language-model system](https://banes-lab.com/api/facets/architecture/scope/language-model-system.md) (2), [latency](https://banes-lab.com/api/facets/architecture/scope/latency.md) (3), [layer](https://banes-lab.com/api/facets/architecture/scope/layer.md) (1), [lazy loading](https://banes-lab.com/api/facets/architecture/scope/lazy-loading.md) (1), [lifecycle](https://banes-lab.com/api/facets/architecture/scope/lifecycle.md) (2), [lifetime](https://banes-lab.com/api/facets/architecture/scope/lifetime.md) (2), [liveness](https://banes-lab.com/api/facets/architecture/scope/liveness.md) (1), [measurement](https://banes-lab.com/api/facets/architecture/scope/measurement.md) (1), [memory](https://banes-lab.com/api/facets/architecture/scope/memory.md) (3), [message](https://banes-lab.com/api/facets/architecture/scope/message.md) (7), [message handler](https://banes-lab.com/api/facets/architecture/scope/message-handler.md) (1), [message handling](https://banes-lab.com/api/facets/architecture/scope/message-handling.md) (1), [messaging](https://banes-lab.com/api/facets/architecture/scope/messaging.md) (7), [metadata](https://banes-lab.com/api/facets/architecture/scope/metadata.md) (3), [metaprogramming](https://banes-lab.com/api/facets/architecture/scope/metaprogramming.md) (1), [metaprogramming_modeling](https://banes-lab.com/api/facets/architecture/scope/metaprogramming-modeling.md) (1), [method](https://banes-lab.com/api/facets/architecture/scope/method.md) (4), [ML](https://banes-lab.com/api/facets/architecture/scope/ml.md) (1), [ML pipeline](https://banes-lab.com/api/facets/architecture/scope/ml-pipeline.md) (1), [model](https://banes-lab.com/api/facets/architecture/scope/model.md) (3), [model lifecycle](https://banes-lab.com/api/facets/architecture/scope/model-lifecycle.md) (2), [model serving](https://banes-lab.com/api/facets/architecture/scope/model-serving.md) (2), [model_governance](https://banes-lab.com/api/facets/architecture/scope/model-governance.md) (11), [model-backed feature](https://banes-lab.com/api/facets/architecture/scope/model-backed-feature.md) (1), [model-backed system](https://banes-lab.com/api/facets/architecture/scope/model-backed-system.md) (7), [modeling](https://banes-lab.com/api/facets/architecture/scope/modeling.md) (1), [modularity](https://banes-lab.com/api/facets/architecture/scope/modularity.md) (21), [module](https://banes-lab.com/api/facets/architecture/scope/module.md) (38), [module behavior](https://banes-lab.com/api/facets/architecture/scope/module-behavior.md) (1), [naming](https://banes-lab.com/api/facets/architecture/scope/naming.md) (1), [network](https://banes-lab.com/api/facets/architecture/scope/network.md) (7), [new codebase](https://banes-lab.com/api/facets/architecture/scope/new-codebase.md) (1), [object construction](https://banes-lab.com/api/facets/architecture/scope/object-construction.md) (1), [object coordination](https://banes-lab.com/api/facets/architecture/scope/object-coordination.md) (1), [object_creation](https://banes-lab.com/api/facets/architecture/scope/object-creation.md) (4), [observability_traceability](https://banes-lab.com/api/facets/architecture/scope/observability-traceability.md) (2), [operation](https://banes-lab.com/api/facets/architecture/scope/operation.md) (3), [operations](https://banes-lab.com/api/facets/architecture/scope/operations.md) (5), [ordering](https://banes-lab.com/api/facets/architecture/scope/ordering.md) (1), [organization](https://banes-lab.com/api/facets/architecture/scope/organization.md) (4), [package](https://banes-lab.com/api/facets/architecture/scope/package.md) (5), [parallelism](https://banes-lab.com/api/facets/architecture/scope/parallelism.md) (1), [parser](https://banes-lab.com/api/facets/architecture/scope/parser.md) (3), [performance](https://banes-lab.com/api/facets/architecture/scope/performance.md) (1), [performance_scaling](https://banes-lab.com/api/facets/architecture/scope/performance-scaling.md) (1), [persistence](https://banes-lab.com/api/facets/architecture/scope/persistence.md) (6), [pipeline](https://banes-lab.com/api/facets/architecture/scope/pipeline.md) (5), [platform](https://banes-lab.com/api/facets/architecture/scope/platform.md) (8), [plugin](https://banes-lab.com/api/facets/architecture/scope/plugin.md) (9), [policy](https://banes-lab.com/api/facets/architecture/scope/policy.md) (1), [process](https://banes-lab.com/api/facets/architecture/scope/process.md) (9), [processing](https://banes-lab.com/api/facets/architecture/scope/processing.md) (3), [product](https://banes-lab.com/api/facets/architecture/scope/product.md) (2), [product family](https://banes-lab.com/api/facets/architecture/scope/product-family.md) (1), [production](https://banes-lab.com/api/facets/architecture/scope/production.md) (1), [protocol](https://banes-lab.com/api/facets/architecture/scope/protocol.md) (7), [queue](https://banes-lab.com/api/facets/architecture/scope/queue.md) (3), [RAG](https://banes-lab.com/api/facets/architecture/scope/rag.md) (1), [reader](https://banes-lab.com/api/facets/architecture/scope/reader.md) (1), [reasoning](https://banes-lab.com/api/facets/architecture/scope/reasoning.md) (2), [record](https://banes-lab.com/api/facets/architecture/scope/record.md) (3), [redundancy](https://banes-lab.com/api/facets/architecture/scope/redundancy.md) (1), [refactor](https://banes-lab.com/api/facets/architecture/scope/refactor.md) (1), [release](https://banes-lab.com/api/facets/architecture/scope/release.md) (4), [reliability](https://banes-lab.com/api/facets/architecture/scope/reliability.md) (1), [remote access](https://banes-lab.com/api/facets/architecture/scope/remote-access.md) (1), [replication](https://banes-lab.com/api/facets/architecture/scope/replication.md) (2), [report](https://banes-lab.com/api/facets/architecture/scope/report.md) (3), [repository](https://banes-lab.com/api/facets/architecture/scope/repository.md) (7), [reproducibility](https://banes-lab.com/api/facets/architecture/scope/reproducibility.md) (1), [request](https://banes-lab.com/api/facets/architecture/scope/request.md) (2), [request handling](https://banes-lab.com/api/facets/architecture/scope/request-handling.md) (1), [requirement](https://banes-lab.com/api/facets/architecture/scope/requirement.md) (1), [resilience](https://banes-lab.com/api/facets/architecture/scope/resilience.md) (3), [resilience_recovery](https://banes-lab.com/api/facets/architecture/scope/resilience-recovery.md) (5), [resource](https://banes-lab.com/api/facets/architecture/scope/resource.md) (2), [resource boundary](https://banes-lab.com/api/facets/architecture/scope/resource-boundary.md) (1), [resource pool](https://banes-lab.com/api/facets/architecture/scope/resource-pool.md) (1), [retrieval](https://banes-lab.com/api/facets/architecture/scope/retrieval.md) (2), [risk](https://banes-lab.com/api/facets/architecture/scope/risk.md) (1), [role](https://banes-lab.com/api/facets/architecture/scope/role.md) (1), [root](https://banes-lab.com/api/facets/architecture/scope/root.md) (4), [rule](https://banes-lab.com/api/facets/architecture/scope/rule.md) (1), [rules](https://banes-lab.com/api/facets/architecture/scope/rules.md) (1), [run](https://banes-lab.com/api/facets/architecture/scope/run.md) (3), [runtime](https://banes-lab.com/api/facets/architecture/scope/runtime.md) (43), [runtime_extensibility](https://banes-lab.com/api/facets/architecture/scope/runtime-extensibility.md) (2), [scalability](https://banes-lab.com/api/facets/architecture/scope/scalability.md) (3), [schema](https://banes-lab.com/api/facets/architecture/scope/schema.md) (7), [search](https://banes-lab.com/api/facets/architecture/scope/search.md) (1), [section](https://banes-lab.com/api/facets/architecture/scope/section.md) (1), [security](https://banes-lab.com/api/facets/architecture/scope/security.md) (10), [security_governance](https://banes-lab.com/api/facets/architecture/scope/security-governance.md) (8), [semantic_consistency](https://banes-lab.com/api/facets/architecture/scope/semantic-consistency.md) (5), [serialization](https://banes-lab.com/api/facets/architecture/scope/serialization.md) (1), [service](https://banes-lab.com/api/facets/architecture/scope/service.md) (82), [service boundary](https://banes-lab.com/api/facets/architecture/scope/service-boundary.md) (4), [service communication](https://banes-lab.com/api/facets/architecture/scope/service-communication.md) (1), [service mesh](https://banes-lab.com/api/facets/architecture/scope/service-mesh.md) (1), [service workflow](https://banes-lab.com/api/facets/architecture/scope/service-workflow.md) (1), [services](https://banes-lab.com/api/facets/architecture/scope/services.md) (2), [sharing](https://banes-lab.com/api/facets/architecture/scope/sharing.md) (1), [staging](https://banes-lab.com/api/facets/architecture/scope/staging.md) (1), [startup](https://banes-lab.com/api/facets/architecture/scope/startup.md) (1), [state](https://banes-lab.com/api/facets/architecture/scope/state.md) (1), [state capture](https://banes-lab.com/api/facets/architecture/scope/state-capture.md) (1), [state machine](https://banes-lab.com/api/facets/architecture/scope/state-machine.md) (1), [state modeling](https://banes-lab.com/api/facets/architecture/scope/state-modeling.md) (2), [state_transaction](https://banes-lab.com/api/facets/architecture/scope/state-transaction.md) (8), [storage](https://banes-lab.com/api/facets/architecture/scope/storage.md) (3), [stream](https://banes-lab.com/api/facets/architecture/scope/stream.md) (9), [stream processing](https://banes-lab.com/api/facets/architecture/scope/stream-processing.md) (1), [stream processor](https://banes-lab.com/api/facets/architecture/scope/stream-processor.md) (1), [streaming](https://banes-lab.com/api/facets/architecture/scope/streaming.md) (1), [structure](https://banes-lab.com/api/facets/architecture/scope/structure.md) (2), [subsystem](https://banes-lab.com/api/facets/architecture/scope/subsystem.md) (1), [surface](https://banes-lab.com/api/facets/architecture/scope/surface.md) (6), [system](https://banes-lab.com/api/facets/architecture/scope/system.md) (47), [system family](https://banes-lab.com/api/facets/architecture/scope/system-family.md) (1), [team](https://banes-lab.com/api/facets/architecture/scope/team.md) (3), [test](https://banes-lab.com/api/facets/architecture/scope/test.md) (4), [time](https://banes-lab.com/api/facets/architecture/scope/time.md) (1), [tooling](https://banes-lab.com/api/facets/architecture/scope/tooling.md) (2), [topology](https://banes-lab.com/api/facets/architecture/scope/topology.md) (2), [traffic](https://banes-lab.com/api/facets/architecture/scope/traffic.md) (1), [transaction](https://banes-lab.com/api/facets/architecture/scope/transaction.md) (7), [traversal](https://banes-lab.com/api/facets/architecture/scope/traversal.md) (1), [tree](https://banes-lab.com/api/facets/architecture/scope/tree.md) (1), [type hierarchy](https://banes-lab.com/api/facets/architecture/scope/type-hierarchy.md) (2), [UI](https://banes-lab.com/api/facets/architecture/scope/ui.md) (2), [unit of work](https://banes-lab.com/api/facets/architecture/scope/unit-of-work.md) (1), [user](https://banes-lab.com/api/facets/architecture/scope/user.md) (4), [user flow](https://banes-lab.com/api/facets/architecture/scope/user-flow.md) (1), [UX](https://banes-lab.com/api/facets/architecture/scope/ux.md) (2), [value object](https://banes-lab.com/api/facets/architecture/scope/value-object.md) (1), [venue](https://banes-lab.com/api/facets/architecture/scope/venue.md) (1), [verification](https://banes-lab.com/api/facets/architecture/scope/verification.md) (1), [visibility](https://banes-lab.com/api/facets/architecture/scope/visibility.md) (1), [vocabulary](https://banes-lab.com/api/facets/architecture/scope/vocabulary.md) (3), [web](https://banes-lab.com/api/facets/architecture/scope/web.md) (1), [workflow](https://banes-lab.com/api/facets/architecture/scope/workflow.md) (13), [workload](https://banes-lab.com/api/facets/architecture/scope/workload.md) (1)

## Entries

- [Big Ball of Mud](https://banes-lab.com/records/architecture/big-ball-of-mud.md): A defect in which a system has no discernible boundaries, so any part can depend on and change any other.
- [God Object](https://banes-lab.com/records/architecture/god-object.md): A defect in which one object accumulates unrelated responsibilities and becomes the default place for every change.
- [Concrete Coupling](https://banes-lab.com/records/architecture/concrete-coupling.md): A defect in which high-level policy depends directly on concrete implementations instead of on abstractions.
- [Schema Drift](https://banes-lab.com/records/architecture/schema-drift.md): A defect in which the producers, consumers and stores of one payload evolve its shape independently until its meaning diverges.
- [Implicit Contract](https://banes-lab.com/records/architecture/implicit-contract.md): A defect in which a boundary's assumptions, including the shape and meaning of the data it passes, live in behavior, naming or ordering rather than in a declared contract.
- [Hardcoded Configuration](https://banes-lab.com/records/architecture/hardcoded-configuration.md): A defect in which environment, credential or policy values are written into code instead of being supplied as configuration.
- [Shared Mutable State](https://banes-lab.com/records/architecture/shared-mutable-state.md): A defect in which writable state is shared across modules with no owner and no synchronization.
- [Boundary Leakage](https://banes-lab.com/records/architecture/boundary-leakage.md): A defect in which internal, persistence or vendor types cross an architectural boundary.
- [Manual-Only Governance](https://banes-lab.com/records/architecture/manual-only-governance.md): A defect in which architecture rules or security policies exist only in documents or in reviewers' memory, with no executable check, so they drift from what the system does.
- [Opaque Runtime Behavior](https://banes-lab.com/records/architecture/opaque-runtime-behavior.md): A defect in which runtime behavior emerges from hidden reflection, registration or binding that nothing reports, so the runtime's structure and state cannot be inspected.
- [Unowned Risk](https://banes-lab.com/records/architecture/unowned-risk.md): A defect in which a risk is never identified, or is identified and has no owner, severity, mitigation or review date.
- [Unobservable Failure](https://banes-lab.com/records/architecture/unobservable-failure.md): A defect in which an operation can fail without leaving a log, metric, trace or error contract.
- [Unversioned Breaking Change](https://banes-lab.com/records/architecture/unversioned-breaking-change.md): A defect in which a public contract changes incompatibly without a version, a deprecation path or a compatibility test.
- [Distributed Monolith](https://banes-lab.com/records/architecture/distributed-monolith.md): A defect in which services are deployed separately but still share data, transactions and release cycles.
- [Shotgun Surgery](https://banes-lab.com/records/architecture/shotgun-surgery.md): A defect in which one responsibility is scattered so that a single change needs edits in many files.
- [Divergent Change](https://banes-lab.com/records/architecture/divergent-change.md): A defect in which one module changes for many unrelated reasons.
- [Feature Envy](https://banes-lab.com/records/architecture/feature-envy.md): A defect in which one module mostly works on another module's data instead of its own.
- [Inappropriate Intimacy](https://banes-lab.com/records/architecture/inappropriate-intimacy.md): A defect in which modules depend on each other's internal structure or private state.
- [Message Chain](https://banes-lab.com/records/architecture/message-chain.md): A defect in which a client navigates a chain of objects to reach the behavior it needs.
- [Middle Man](https://banes-lab.com/records/architecture/middle-man.md): A defect in which a module delegates almost every call without adding behavior of its own.
- [Data Clumps](https://banes-lab.com/records/architecture/data-clumps.md): A defect in which the same group of values travels together without being named as one type.
- [Primitive Obsession](https://banes-lab.com/records/architecture/primitive-obsession.md): A defect in which domain concepts are held in raw primitives with no type or validation.
- [Stringly Typed Programming](https://banes-lab.com/records/architecture/stringly-typed-programming.md): A defect in which states, types or permissions are encoded as unchecked strings.
- [Boolean Trap](https://banes-lab.com/records/architecture/boolean-trap.md): A defect in which boolean parameters hide the intent of a call site.
- [Long Parameter List](https://banes-lab.com/records/architecture/long-parameter-list.md): A defect in which a signature grows so many parameters that a caller can no longer read or validate it.
- [Magic Value](https://banes-lab.com/records/architecture/magic-value.md): A defect in which policy, thresholds or states are written as unexplained literals.
- [Speculative Generality](https://banes-lab.com/records/architecture/speculative-generality.md): A defect in which abstractions are built for variation that has no evidence of arriving.
- [Premature Abstraction](https://banes-lab.com/records/architecture/premature-abstraction.md): A defect in which a shared abstraction is extracted before its variation is understood, so it fits no caller well.
- [Over-Abstraction](https://banes-lab.com/records/architecture/over-abstraction.md): A defect in which layers, interfaces and factories outnumber the variation they serve.
- [Golden Hammer](https://banes-lab.com/records/architecture/golden-hammer.md): A defect in which one familiar solution is applied to problems regardless of fit.
- [Pattern Cargo Cult](https://banes-lab.com/records/architecture/pattern-cargo-cult.md): A defect in which a pattern's name and shape are copied without the forces, contracts and checks that make it work.
- [Lava Flow](https://banes-lab.com/records/architecture/lava-flow.md): A defect in which obsolete or half-migrated code survives because nothing records whether it is still needed.
- [Zombie Code](https://banes-lab.com/records/architecture/zombie-code.md): A defect in which unreachable or disabled code stays in the system and misleads the developer and the model.
- [Temporal Coupling](https://banes-lab.com/records/architecture/temporal-coupling.md): A defect in which operations must be called in an undocumented order to work.
- [Hidden Side Effect](https://banes-lab.com/records/architecture/hidden-side-effect.md): A defect in which an operation that looks like a query mutates state or performs I/O that its name and signature do not show.
- [Action at a Distance](https://banes-lab.com/records/architecture/action-at-a-distance.md): A defect in which one part of the system changes behavior elsewhere through globals, patches or implicit listeners.
- [Ambient Context](https://banes-lab.com/records/architecture/ambient-context.md): A defect in which request, tenant or user state is read from implicit global context.
- [Inconsistent Error Model](https://banes-lab.com/records/architecture/inconsistent-error-model.md): A defect in which one class of failure is reported through several incompatible shapes.
- [Exception Control Flow](https://banes-lab.com/records/architecture/exception-control-flow.md): A defect in which exceptions carry expected branching or normal absence.
- [Null Semantics Drift](https://banes-lab.com/records/architecture/null-semantics-drift.md): A defect in which null, empty, zero and missing are used interchangeably for one field.
- [Anemic Domain Model](https://banes-lab.com/records/architecture/anemic-domain-model.md): A defect in which domain objects hold data only, while their rules live in services and handlers.
- [Transaction Script Sprawl](https://banes-lab.com/records/architecture/transaction-script-sprawl.md): A defect in which business processes are procedural scripts that coordinate validation, persistence and decisions directly.
- [Fat Controller](https://banes-lab.com/records/architecture/fat-controller.md): A defect in which controllers hold validation, business rules, persistence and response formatting.
- [Repository Dump](https://banes-lab.com/records/architecture/repository-dump.md): A defect in which a repository accumulates business queries, policy and orchestration until it is a second service layer.
- [Utility Dump](https://banes-lab.com/records/architecture/utility-dump.md): A defect in which unrelated helpers accumulate in a generic utility module that no one owns.
- [Framework Leakage](https://banes-lab.com/records/architecture/framework-leakage.md): A defect in which framework or infrastructure types, annotations or lifecycles enter core domain logic, so business rules depend on technical specifics.
- [Vendor Lock-In Leakage](https://banes-lab.com/records/architecture/vendor-lock-in-leakage.md): A defect in which an external system's or a vendor's APIs, errors and models spread through application and domain code, so their changes ripple across it.
- [Circular Dependency](https://banes-lab.com/records/architecture/circular-dependency.md): A defect in which modules depend on each other, directly or through others, so none can change alone.
- [Cyclic Deployment Dependency](https://banes-lab.com/records/architecture/cyclic-deployment-dependency.md): A defect in which services must deploy in lockstep because each depends on the other's current version.
- [Synchronous Chain Trap](https://banes-lab.com/records/architecture/synchronous-chain-trap.md): A defect in which one request depends on a deep chain of blocking synchronous remote calls, so one slow link stalls the whole request.
- [Chatty Interface](https://banes-lab.com/records/architecture/chatty-interface.md): A defect in which one operation needs many small remote calls.
- [N Plus One Query](https://banes-lab.com/records/architecture/n-plus-one-query.md): A defect in which a collection is fetched and then one further query is issued per item.
- [Cache Poisoning by Design](https://banes-lab.com/records/architecture/cache-poisoning-by-design.md): A defect in which a cache key omits an input the entry depends on, so one request is served another's result.
- [Retry Storm](https://banes-lab.com/records/architecture/retry-storm.md): A defect in which clients retry a failing dependency so aggressively that the retries prolong the failure.
- [Timeout Omission](https://banes-lab.com/records/architecture/timeout-omission.md): A defect in which calls to external systems carry no timeout, cancellation or deadline, so a caller can wait for ever on work that never completes.
- [Missing Backpressure](https://banes-lab.com/records/architecture/missing-backpressure.md): A defect in which a system accepts work faster than it can process it, with no limit or shedding.
- [Silent Data Corruption](https://banes-lab.com/records/architecture/silent-data-corruption.md): A defect in which invalid data is accepted, transformed or stored without any check noticing.
- [Lost Update](https://banes-lab.com/records/architecture/lost-update.md): A defect in which concurrent writers overwrite each other's changes without a version check.
- [Dual Write](https://banes-lab.com/records/architecture/dual-write.md): A defect in which related state is written to two systems with no atomicity or compensation.
- [Read-Your-Writes Violation](https://banes-lab.com/records/architecture/read-your-writes-violation.md): A defect in which a writer reads back a stale copy of what it has just written.
- [Security Theater](https://banes-lab.com/records/architecture/security-theater.md): A defect in which visible security controls leave the real threat unreduced, or can be bypassed.
- [Authorization Scattering](https://banes-lab.com/records/architecture/authorization-scattering.md): A defect in which authorization checks are spread across layers with no central policy.
- [Secret Sprawl](https://banes-lab.com/records/architecture/secret-sprawl.md): A defect in which credentials and keys are stored across code, logs and configuration.
- [Personal Data Oversharing](https://banes-lab.com/records/architecture/personal-data-oversharing.md): A defect in which more personal data is collected, kept, logged or exposed than the declared purpose needs.
- [Observability Noise](https://banes-lab.com/records/architecture/observability-noise.md): A defect in which logs, metrics and alerts are too many and too low in signal to act on.
- [Log-as-Control-Flow](https://banes-lab.com/records/architecture/log-as-control-flow.md): A defect in which a failure is logged as though logging handled it, and execution continues.
- [Manual Runbook Dependency](https://banes-lab.com/records/architecture/manual-runbook-dependency.md): A defect in which repeatable operational steps, such as detecting a failure and recovering from it, are performed by hand during incidents and deploys, so recovery waits on a person.
- [Big-Bang Release](https://banes-lab.com/records/architecture/big-bang-release.md): A defect in which a large, irreversible change reaches every user at once, with no staged rollout.
- [Irreversible Migration](https://banes-lab.com/records/architecture/irreversible-migration.md): A defect in which a schema or data change can neither run beside the old version nor be rolled back.
- [Big-Upfront Frozen Architecture](https://banes-lab.com/records/architecture/big-upfront-frozen-architecture.md): A defect in which major architectural decisions are fixed before the forces they answer are known.
- [Architecture Astronaut](https://banes-lab.com/records/architecture/architecture-astronaut.md): A defect in which abstract frameworks, meta-models and architectural structure are built ahead of the concrete needs they should serve.
- [Feature-Only Design](https://banes-lab.com/records/architecture/feature-only-design.md): A defect in which architecture serves immediate features while its quality attributes go unaddressed.
- [Test Pyramid Inversion](https://banes-lab.com/records/architecture/test-pyramid-inversion.md): A defect in which a test suite relies mainly on slow end-to-end tests, with few unit and contract tests.
- [Mock Mirage](https://banes-lab.com/records/architecture/mock-mirage.md): A defect in which tests assert calls on mocks rather than observable behavior or contracts.
- [Flaky Test Normalization](https://banes-lab.com/records/architecture/flaky-test-normalization.md): A defect in which intermittent test failures are accepted and rerun until they pass.
- [Prompt Sprawl](https://banes-lab.com/records/architecture/prompt-sprawl.md): A defect in which prompts, model parameters and output schemas are scattered through code without versions or evaluation.
- [Ungrounded Content](https://banes-lab.com/records/architecture/ungrounded-content.md): A defect in which the model produces answers or decisions without retrieved evidence or disclosed uncertainty.
- [Model Version Ambiguity](https://banes-lab.com/records/architecture/model-version-ambiguity.md): A defect in which models, prompts or indexes are used without recording their version and configuration.
- [Domain-Driven Design (DDD)](https://banes-lab.com/records/architecture/domain-driven-design.md): A convention of modeling software on the business domain's own language, split into bounded contexts with a domain model in each.
- [Domain Model](https://banes-lab.com/records/architecture/domain-model.md): A formal definition of the business concepts, rules and invariants of one context, written as types with behavior.
- [Bounded Context](https://banes-lab.com/records/architecture/bounded-context.md): A rule or precondition that each domain model holds inside one explicit boundary, where its terms have one meaning.
- [Context Mapping](https://banes-lab.com/records/architecture/context-mapping.md): The activity of recording how bounded contexts relate, including which one is upstream and how their models translate.
- [Anti-Corruption Layer](https://banes-lab.com/records/architecture/anti-corruption-layer.md): A design pattern that translates an external system's model into the local domain's terms at the boundary.
- [Explicit Boundaries](https://banes-lab.com/records/architecture/explicit-boundaries.md): A design rule that each module declares its public interface and owner, and other modules reach it only through that interface.
- [Aggregate](https://banes-lab.com/records/architecture/aggregate.md): A design pattern that groups entities under one root, which is the only entry point and keeps the group's invariants.
- [Value Object](https://banes-lab.com/records/architecture/value-object.md): A design pattern that models a domain value as an immutable, self-validating object compared by its attributes.
- [Entity](https://banes-lab.com/records/architecture/entity.md): A design pattern that models a domain object by a stable identity, which stays the same while its attributes change.
- [Domain Service](https://banes-lab.com/records/architecture/domain-service.md): A design pattern that places a domain rule spanning several entities in a stateless service named in the domain's language.
- [Runtime Discovery](https://banes-lab.com/records/architecture/runtime-discovery.md): A mechanism that finds the available handlers, plugins or services at startup by matching a naming convention, a file pattern or metadata, and registers each one it finds in place of a hand-written list.
- [Service Discovery](https://banes-lab.com/records/architecture/service-discovery.md): A mechanism that resolves a service name to a healthy network endpoint at call time through a registry.
- [Dynamic Binding](https://banes-lab.com/records/architecture/dynamic-binding.md): A mechanism that selects the implementation behind an interface at runtime, from configuration or a registry, so the choice is made at bootstrap or first use rather than fixed in code.
- [Dynamic Dispatch](https://banes-lab.com/records/architecture/dynamic-dispatch.md): A mechanism that chooses which operation runs from the receiver or a keyed table at runtime, replacing a conditional over kinds.
- [Runtime Extensibility](https://banes-lab.com/records/architecture/runtime-extensibility.md): The degree to which new capability can be added to a running system through extension points, without modifying its core.
- [Causality](https://banes-lab.com/records/architecture/causality.md): A design rule that every effect records the event that caused it, so its order can be reasoned about.
- [Causal Consistency](https://banes-lab.com/records/architecture/causal-consistency.md): A conceptual representation of a consistency guarantee in which no reader sees an effect before its cause.
- [Happens-Before Relationship](https://banes-lab.com/records/architecture/happens-before-relationship.md): A conceptual representation of the partial order in which one operation is known to precede another.
- [Event Ordering](https://banes-lab.com/records/architecture/event-ordering.md): A rule or precondition that a stateful consumer processes the events of one key in their sequence order.
- [Causal Dependency](https://banes-lab.com/records/architecture/causal-dependency.md): A conceptual representation of one step or event that cannot proceed until another has happened.
- [Dependency Graph](https://banes-lab.com/records/architecture/dependency-graph.md): Descriptive data about which modules, tasks or services depend on which, extracted as a directed graph.
- [Directed Acyclic Graph (DAG)](https://banes-lab.com/records/architecture/directed-acyclic-graph.md): A rule or precondition that every dependency points one way and the graph they form has no cycle, so its nodes can be put in topological order.
- [Vector Clocks](https://banes-lab.com/records/architecture/vector-clocks.md): A mechanism that keeps one counter per node on each update, so two updates can be compared as ordered or concurrent.
- [Lamport Clocks](https://banes-lab.com/records/architecture/lamport-clocks.md): A mechanism that stamps each event with a logical counter, advanced on every send and receive, to give a partial order.
- [Hybrid Logical Clocks](https://banes-lab.com/records/architecture/hybrid-logical-clocks.md): A mechanism that combines physical time with a logical counter, so timestamps follow causal order and stay close to wall-clock time.
- [CRDTs](https://banes-lab.com/records/architecture/crdts.md): A mechanism that stores replicated state in data types whose merge is commutative, so replicas converge without coordination.
- [Total-Order Broadcast](https://banes-lab.com/records/architecture/total-order-broadcast.md): A mechanism that delivers every message to every node in the same order, agreed by consensus.
- [CAP Theorem](https://banes-lab.com/records/architecture/cap-theorem.md): A conceptual representation of the choice a distributed store makes during a network partition, between consistency and availability.
- [PACELC Theorem](https://banes-lab.com/records/architecture/pacelc-theorem.md): A conceptual representation that extends the CAP theorem with the trade-off a healthy network still forces, between latency and consistency.
- [Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md): A design rule that every operation states the preconditions it needs, the postconditions it guarantees and the invariants it keeps.
- [Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md): A design rule that every boundary declares the shape and meaning of what crosses it in a typed contract.
- [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md): The degree to which a public interface keeps its signatures and meaning across releases.
- [Interface-Based Design](https://banes-lab.com/records/architecture/interface-based-design.md): A design rule that a module depends on interfaces, and the implementation behind each one is supplied from outside.
- [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md): A design rule that a boundary's contract is written and agreed before the implementation behind it.
- [API Contract](https://banes-lab.com/records/architecture/api-contract.md): A rule or precondition that each endpoint declares its request, response and error shapes in a versioned schema.
- [Service Contract](https://banes-lab.com/records/architecture/service-contract.md): A rule or precondition that a service declares its operations, their results and their side effects to every consumer.
- [Data Contract](https://banes-lab.com/records/architecture/data-contract.md): A rule or precondition that data exchanged between parties has declared fields, types, nullability and meaning.
- [Schema Contract](https://banes-lab.com/records/architecture/schema-contract.md): A rule or precondition that every payload is validated against a machine-readable schema at the boundary it crosses.
- [Semantic Contracts](https://banes-lab.com/records/architecture/semantic-contracts.md): A rule or precondition that each term and value at a boundary has one agreed meaning, beyond its type.
- [Preconditions](https://banes-lab.com/records/architecture/preconditions.md): A rule or precondition that must hold on an operation's input and state before the operation runs.
- [Postconditions](https://banes-lab.com/records/architecture/postconditions.md): A rule or precondition that an operation's result and resulting state must satisfy when it returns.
- [Invariant](https://banes-lab.com/records/architecture/invariant.md): A rule or precondition that holds for an entity or aggregate in every state it can reach.
- [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md): A rule or precondition that a new version keeps working for consumers written against an older one.
- [Forward Compatibility](https://banes-lab.com/records/architecture/forward-compatibility.md): A rule or precondition that an older reader accepts data from a newer writer by ignoring the fields it does not know rather than failing on them.
- [Versioning](https://banes-lab.com/records/architecture/versioning.md): A mechanism that labels each release of an interface or schema, so consumers can tell compatible changes from breaking ones.
- [Protocol Compatibility](https://banes-lab.com/records/architecture/protocol-compatibility.md): A rule or precondition that both ends of a connection speak a declared protocol version they both support.
- [Interoperability](https://banes-lab.com/records/architecture/interoperability.md): The degree to which separate systems exchange data and use it correctly through shared formats and contracts.
- [Uniform Interface](https://banes-lab.com/records/architecture/uniform-interface.md): A rule or precondition that every resource in an API uses the same verbs, response shapes and error format.
- [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md): A rule or precondition that a provider verifies each change against the expectations its consumers have recorded.
- [Control Plane](https://banes-lab.com/records/architecture/control-plane.md): Descriptive data about the desired state of a distributed runtime, held in one place and applied to every node through a management interface.
- [Orchestration](https://banes-lab.com/records/architecture/orchestration.md): A mechanism that runs a multi-step workflow from one coordinator, which calls each step in order and tracks its outcome.
- [Centralized Configuration](https://banes-lab.com/records/architecture/centralized-configuration.md): A design pattern that keeps every service's configuration in one versioned store the services read from.
- [Centralized Authentication](https://banes-lab.com/records/architecture/centralized-authentication.md): A design pattern that verifies identity once, at a shared identity provider, and passes the result to each service.
- [Centralized Logging](https://banes-lab.com/records/architecture/centralized-logging.md): A design pattern that ships structured logs from every instance to one aggregated store.
- [Decentralization](https://banes-lab.com/records/architecture/decentralization.md): A design rule that decisions and runtime control sit with the teams and services that own them, joined by contracts.
- [Leader Election](https://banes-lab.com/records/architecture/leader-election.md): A mechanism that lets a group of nodes agree on one coordinator and replace it when it fails.
- [Consensus](https://banes-lab.com/records/architecture/consensus.md): A mechanism that lets a quorum of nodes commit one value, so every correct node ends up with the same value.
- [Choreography](https://banes-lab.com/records/architecture/choreography.md): A mechanism that coordinates a cross-service flow through events, with each service reacting to the previous one's event.
- [Determinism](https://banes-lab.com/records/architecture/determinism.md): A design rule that the same inputs and state always produce the same result, with time and randomness passed in as inputs.
- [Predictability](https://banes-lab.com/records/architecture/predictability.md): The degree to which a caller can foresee what an operation does from its interface and contract.
- [Referential Transparency](https://banes-lab.com/records/architecture/referential-transparency.md): A design rule that an expression can be replaced by its value without changing the program's behavior.
- [Pure Functions](https://banes-lab.com/records/architecture/pure-functions.md): A technique for writing logic as functions whose result depends only on their arguments and which have no side effects.
- [Immutability](https://banes-lab.com/records/architecture/immutability.md): A design rule that a value is never changed after it is created, and a change produces a new value.
- [Reproducibility](https://banes-lab.com/records/architecture/reproducibility.md): The degree to which a build, test or training run gives the same output from the same pinned inputs on another machine.
- [Repeatability](https://banes-lab.com/records/architecture/repeatability.md): The degree to which rerunning the same test or process in the same environment gives the same result.
- [Correctness](https://banes-lab.com/records/architecture/correctness.md): The degree to which the behavior of code matches its specification.
- [Formal Verification](https://banes-lab.com/records/architecture/formal-verification.md): The activity of proving, against a formal specification, that an algorithm or protocol keeps its invariants for every input.
- [Specification-Based Testing](https://banes-lab.com/records/architecture/specification-based-testing.md): The activity of deriving tests from a specification's stated behavior, independently of how the code implements it.
- [Property-Based Testing](https://banes-lab.com/records/architecture/property-based-testing.md): The activity of checking that a stated property holds for many generated inputs, and shrinking each failure to a minimal counterexample.
- [Static Analysis](https://banes-lab.com/records/architecture/static-analysis.md): A mechanism that checks source code against a ruleset without running it.
- [Testability](https://banes-lab.com/records/architecture/testability.md): The degree to which code can be tested in isolation, with its dependencies, time and randomness supplied by the test.
- [Validation](https://banes-lab.com/records/architecture/validation.md): The activity of checking that inputs and delivered behavior meet the acceptance criteria of their users.
- [Verification](https://banes-lab.com/records/architecture/verification.md): The activity of checking that an implementation conforms to its specification.
- [Portability](https://banes-lab.com/records/architecture/portability.md): The degree to which software runs on another platform or environment without code changes.
- [Platform Independence](https://banes-lab.com/records/architecture/platform-independence.md): A design rule that portable layers reach the operating system and vendor services only through abstractions.
- [Environment Parity](https://banes-lab.com/records/architecture/environment-parity.md): A design rule that development, test, staging and production run the same build, differing only in configuration.
- [Containerization](https://banes-lab.com/records/architecture/containerization.md): A mechanism that packages an application with its runtime dependencies into an image that runs the same on any host.
- [Infrastructure as Code](https://banes-lab.com/records/architecture/infrastructure-as-code.md): The practice of declaring infrastructure in versioned files and provisioning it from them.
- [Standards Compliance](https://banes-lab.com/records/architecture/standards-compliance.md): A rule or precondition that an implementation conforms to the published standard for its protocol, format or domain.
- [Protocol Independence](https://banes-lab.com/records/architecture/protocol-independence.md): A design rule that domain logic is written against ports, and each transport protocol reaches it through its own adapter.
- [Configuration Externalization](https://banes-lab.com/records/architecture/configuration-externalization.md): A design rule that environment-specific values are read from validated external configuration at startup.
- [Immutable Infrastructure](https://banes-lab.com/records/architecture/immutable-infrastructure.md): An approach in which servers are replaced from a new image for every change, instead of being patched in place.
- [Single Responsibility Principle (SRP)](https://banes-lab.com/records/architecture/single-responsibility.md): A design rule that a class or module has one reason to change, because it serves one responsibility.
- [Separation of Concerns](https://banes-lab.com/records/architecture/separation-of-concerns.md): A design rule that parsing, business logic, persistence and presentation each live in their own part of the code.
- [Do Not Repeat Yourself (DRY)](https://banes-lab.com/records/architecture/duplicate-code.md): A design rule that each piece of logic, constant or schema has one source in the code, and every other use refers to it.
- [High Cohesion](https://banes-lab.com/records/architecture/high-cohesion.md): The degree to which the members of a class or module work on the same data towards the same purpose.
- [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md): The degree to which a module can change without forcing changes in the modules around it.
- [Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md): A design rule that an object's state is changed only through its own operations, which keep its invariants.
- [Information Hiding](https://banes-lab.com/records/architecture/information-hiding.md): A design rule that a module exposes an interface and keeps the implementation decisions behind it private.
- [Abstraction](https://banes-lab.com/records/architecture/abstraction.md): A design rule that a concept is expressed by what it does for the code that uses it, and the detail of how it does it stays out of that expression.
- [Modularity](https://banes-lab.com/records/architecture/modularity.md): A design rule that a system is divided into cohesive modules with explicit boundaries and few dependencies between them.
- [Composability](https://banes-lab.com/records/architecture/composability.md): A design rule that parts share compatible interfaces and carry no hidden side effects, so they can be combined into larger parts.
- [Composition Over Inheritance](https://banes-lab.com/records/architecture/composition-over-inheritance.md): A design rule that behavior is reused by holding and delegating to another object instead of extending its class.
- [Reusability](https://banes-lab.com/records/architecture/reusability.md): The degree to which a function or module can serve a new caller without change, because it carries no context of its first one.
- [Replaceability](https://banes-lab.com/records/architecture/replaceability.md): The degree to which a component can be swapped for another implementation of its interface without editing its callers.
- [Interchangeability](https://banes-lab.com/records/architecture/interchangeability.md): The degree to which several implementations conform to one contract closely enough to be selected at runtime.
- [Independence](https://banes-lab.com/records/architecture/independence.md): A design rule that a module can be tested and deployed without the modules around it being present or released.
- [Autonomy](https://banes-lab.com/records/architecture/autonomy.md): A design rule that a service or team owns its data and decisions, so it alone writes its data and others reach or change it only through its published API or events.
- [Interface Segregation Principle (ISP)](https://banes-lab.com/records/architecture/interface-segregation.md): A design rule that a client depends on an interface holding only the methods it uses.
- [Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md): A design rule that high-level policy and low-level detail both depend on an abstraction owned by the policy.
- [Open/Closed Principle (OCP)](https://banes-lab.com/records/architecture/open-closed.md): A design rule that a module gains new behavior by adding code at an extension point, leaving its existing code unchanged.
- [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md): A design rule that a subtype can replace its base type anywhere, because it keeps the base type's preconditions, postconditions and invariants.
- [Polymorphism](https://banes-lab.com/records/architecture/polymorphism.md): A mechanism that lets one interface have several implementations, with the implementation chosen by the object that receives the call.
- [Event-Driven Architecture](https://banes-lab.com/records/architecture/event-driven-architecture.md): A convention of connecting services through published events, with each consumer reacting independently of the producer.
- [Publish/Subscribe Pattern](https://banes-lab.com/records/architecture/publish-subscribe-pattern.md): A design pattern in which publishers send messages to a topic and every subscriber to that topic receives them.
- [Message Queue](https://banes-lab.com/records/architecture/message-queue.md): A mechanism that holds messages durably until a consumer takes and acknowledges each one.
- [Message Broker](https://banes-lab.com/records/architecture/message-broker.md): Descriptive data about topics, queues and routing rules, held by an intermediary service that delivers messages between producers and consumers.
- [Event Bus](https://banes-lab.com/records/architecture/event-bus.md): A mechanism that dispatches each emitted event to the handlers registered for its type.
- [Event Stream](https://banes-lab.com/records/architecture/event-stream.md): A mechanism that keeps events in an ordered, replayable log that consumers read from their own offset.
- [Event Sourcing](https://banes-lab.com/records/architecture/event-sourcing.md): A design pattern that stores state as the sequence of events that produced it and rebuilds current state by replaying them.
- [CQRS](https://banes-lab.com/records/architecture/command-query-responsibility-segregation.md): A design pattern that separates the model that handles commands from the model that answers queries.
- [Domain Events](https://banes-lab.com/records/architecture/domain-events.md): A design pattern that records each significant change in the domain as an event named in the domain's language.
- [Integration Events](https://banes-lab.com/records/architecture/integration-events.md): A design pattern that publishes a versioned public event, mapped from an internal domain event, for consumers outside the service.
- [Asynchronous Communication](https://banes-lab.com/records/architecture/asynchronous-communication.md): A design rule that work the caller does not need at once is sent as a message, so the caller does not wait on it.
- [Eventual Consistency](https://banes-lab.com/records/architecture/eventual-consistency.md): A conceptual representation of a consistency guarantee in which replicas and projections converge once updates stop arriving.
- [Saga Pattern](https://banes-lab.com/records/architecture/saga-pattern.md): A design pattern that runs a cross-service transaction as a sequence of local steps, each paired with a compensating step.
- [Outbox Pattern](https://banes-lab.com/records/architecture/outbox-pattern.md): A design pattern that writes an outgoing message in the same local transaction as the state change, and a relay publishes it afterwards.
- [Compensating Transaction](https://banes-lab.com/records/architecture/compensating-transaction.md): A mechanism that undoes the business effect of a completed step when a later step of the workflow fails.
- [Append-Only Log](https://banes-lab.com/records/architecture/append-only-log.md): A design pattern that records history as immutable entries added at the end of the log.
- [Dead-Letter Queue](https://banes-lab.com/records/architecture/dead-letter-queue.md): A design pattern that moves a message which keeps failing into a separate queue, where it can be inspected and reprocessed.
- [Idempotent Consumer](https://banes-lab.com/records/architecture/idempotent-consumer.md): A design pattern in which a consumer records each message it has processed, so a redelivered message has no second effect.
- [Competing Consumers](https://banes-lab.com/records/architecture/competing-consumers.md): A design pattern in which several consumers read from one queue, and each message goes to only one of them.
- [Defensive Programming](https://banes-lab.com/records/architecture/defensive-programming.md): A design rule that code checks its inputs and assumptions before acting on them, and reports a violation as an explicit error.
- [Fail Fast](https://banes-lab.com/records/architecture/fail-fast.md): A design rule that invalid input or state stops the operation at the point it is detected, with an explicit error.
- [Fail Safe](https://banes-lab.com/records/architecture/fail-safe.md): A design rule that a failing operation leaves the system in the state that causes the least harm.
- [Fail Secure](https://banes-lab.com/records/architecture/fail-secure.md): A design rule that an authentication or policy failure denies access.
- [Graceful Degradation](https://banes-lab.com/records/architecture/graceful-degradation.md): A design rule that the failure of an optional dependency removes only the feature it serves, and the rest of the system keeps working.
- [Fault Tolerance](https://banes-lab.com/records/architecture/fault-tolerance.md): The degree to which a system keeps operating correctly when some of its components fail.
- [Resilience](https://banes-lab.com/records/architecture/resilience.md): The degree to which a system contains failures, stays stable under stress and recovers.
- [Robustness Principle](https://banes-lab.com/records/architecture/robustness-principle.md): A design rule that a component is strict in what it sends and tolerant of harmless variation in what it receives.
- [Error Handling](https://banes-lab.com/records/architecture/error-handling.md): A design rule that every error is either handled with its context kept, or propagated as a typed error the caller must handle.
- [Error Boundaries](https://banes-lab.com/records/architecture/error-boundaries.md): A design pattern that catches failures at a component boundary, so a failing part renders or returns an error while the rest keeps running.
- [Fallback Pattern](https://banes-lab.com/records/architecture/fallback-pattern.md): A design pattern that routes a failed call to an alternate provider or response declared in advance.
- [Retry Pattern](https://banes-lab.com/records/architecture/retry-pattern.md): A design pattern that repeats an idempotent call after a transient failure, a bounded number of times with backoff.
- [Timeout Pattern](https://banes-lab.com/records/architecture/timeout-pattern.md): A design pattern that gives every external call a time budget and fails the call when the budget runs out.
- [Circuit Breaker Pattern](https://banes-lab.com/records/architecture/circuit-breaker-pattern.md): A design pattern that stops calling a dependency after repeated failures and probes it again after a wait.
- [Bulkhead Pattern](https://banes-lab.com/records/architecture/bulkhead-pattern.md): A design pattern that gives each workload its own pool of threads or connections, so one workload cannot exhaust the others.
- [Backpressure](https://banes-lab.com/records/architecture/backpressure.md): A mechanism that lets a consumer signal its capacity, so a producer slows down when the consumer falls behind.
- [Assessment](https://banes-lab.com/records/architecture/assessment.md): The activity of evaluating a codebase or architecture against stated criteria, using collected evidence.
- [Architecture Review](https://banes-lab.com/records/architecture/architecture-review.md): The activity of examining a structural change against the architecture's criteria and recorded decisions before it is accepted.
- [Design Review](https://banes-lab.com/records/architecture/design-review.md): The activity of checking a component or feature design for contracts, failure modes and testability before it is built.
- [Code Review](https://banes-lab.com/records/architecture/code-review.md): The activity of having a second party read a code change against review standards before it merges.
- [Impact Analysis](https://banes-lab.com/records/architecture/impact-analysis.md): The activity of tracing a change through the dependency graph to find every consumer it affects.
- [Gap Analysis](https://banes-lab.com/records/architecture/gap-analysis.md): The activity of comparing the current state of a system with its target state and listing each difference.
- [Fitness Functions](https://banes-lab.com/records/architecture/fitness-functions.md): A mechanism that turns an architecture rule into an executable check the pipeline runs on every change.
- [Quality Attributes](https://banes-lab.com/records/architecture/quality-attributes.md): A conceptual representation of the non-functional properties a system must meet, each stated as a measurable scenario.
- [Architecture Decision Records (ADR)](https://banes-lab.com/records/architecture/architecture-decision-records.md): A formal definition of one architecture decision, recording its context, the choice made and its consequences.
- [Evolutionary Architecture](https://banes-lab.com/records/architecture/evolutionary-architecture.md): An approach in which the architecture changes in small increments, each guarded by fitness functions.
- [Minimum Viable Architecture](https://banes-lab.com/records/architecture/minimum-viable-architecture.md): An approach in which a system starts with only the structure its current quality attributes require, and defers the rest until a force demands it.
- [Greenfield Development](https://banes-lab.com/records/architecture/greenfield-development.md): An abstraction of building a new system with no inherited code, so its boundaries are designed from the current forces.
- [First-Principles Design](https://banes-lab.com/records/architecture/first-principles-design.md): An approach in which a design is derived from the problem's forces and invariants before any known pattern is chosen.
- [Reference Architecture](https://banes-lab.com/records/architecture/reference-architecture.md): A formal definition of the modules, patterns and allowed dependencies that a family of systems instantiates.
- [Pattern Consistency](https://banes-lab.com/records/architecture/pattern-consistency.md): The degree to which one kind of problem is solved with the same pattern throughout a codebase.
- [Architectural Consistency](https://banes-lab.com/records/architecture/architectural-consistency.md): The degree to which the code follows the system's declared boundaries, layers and dependency rules.
- [Standardization](https://banes-lab.com/records/architecture/standardization.md): A design rule that one format, tool or pattern is chosen for each recurring concern and applied everywhere it occurs.
- [Self-Describing Architecture](https://banes-lab.com/records/architecture/self-describing-architecture.md): A design rule that each module declares its name, version, capabilities and requirements in metadata that tools and the runtime can read.
- [Self-Describing API](https://banes-lab.com/records/architecture/self-describing-api.md): A design rule that an API publishes machine-readable descriptions of its operations, payloads and errors.
- [Self-Describing Structures](https://banes-lab.com/records/architecture/self-describing-structures.md): A design rule that a data structure carries its own type tags and field names, so a reader can interpret it without outside knowledge.
- [Metadata-Driven Design](https://banes-lab.com/records/architecture/metadata-driven-design.md): An approach in which behavior such as forms, routes or plugins is generated from validated metadata instead of written case by case.
- [Declarative Configuration](https://banes-lab.com/records/architecture/declarative-configuration.md): A design rule that a system's settings are declared as validated data, and the system configures itself from that data.
- [Convention over Configuration](https://banes-lab.com/records/architecture/convention-over-configuration.md): A design rule that a framework infers settings from stable naming and placement conventions, and explicit configuration covers only the exceptions.
- [Capability Declaration](https://banes-lab.com/records/architecture/capability-declaration.md): A mechanism by which a plugin or service lists the operations it supports, so callers test the list instead of probing for methods.
- [Manifest-Based Design](https://banes-lab.com/records/architecture/manifest-based-design.md): A design pattern that loads modules or plugins from a validated manifest listing each entry, version and dependency.
- [Homoiconicity](https://banes-lab.com/records/architecture/homoiconicity.md): The degree to which a language represents its programs in its own data structures, so programs can be inspected and transformed as data.
- [Code as Data](https://banes-lab.com/records/architecture/code-as-data.md): A design rule that logic to be generated or transformed is held as a typed data structure, such as a syntax tree, that tools can inspect and rewrite.
- [Metaprogramming](https://banes-lab.com/records/architecture/metaprogramming.md): A technique for writing programs that generate or transform other programs, at compile time or at runtime.
- [Reflection](https://banes-lab.com/records/architecture/reflection.md): A mechanism that lets a program read and act on type metadata about its own structure at runtime.
- [Introspection](https://banes-lab.com/records/architecture/introspection.md): A mechanism that lets a program query an object's type and public members at runtime without changing them.
- [Compile-Time Evaluation](https://banes-lab.com/records/architecture/compile-time-evaluation.md): A mechanism that computes values, checks or generated code during the build, so the work and its errors happen before runtime.
- [Runtime Code Generation](https://banes-lab.com/records/architecture/runtime-code-generation.md): A mechanism that builds executable code while the program runs, from a specification such as a field mapping.
- [Domain-Specific Language (DSL)](https://banes-lab.com/records/architecture/domain-specific-language.md): A design pattern that expresses a domain's rules or workflows in a small language with a defined grammar and a validator.
- [Language-Oriented Programming](https://banes-lab.com/records/architecture/language-oriented-programming.md): An approach in which each problem domain gets its own language, with a type checker and an evaluator, and solutions are written in it.
- [Model-Driven Architecture](https://banes-lab.com/records/architecture/model-driven-architecture.md): An approach in which a formal model is the source of truth and the implementation is generated from it by transformation rules.
- [Artificial Intelligence Architecture](https://banes-lab.com/records/architecture/artificial-intelligence-architecture.md): A conceptual representation of a system that calls a model behind validated inputs, grounded context, schema-checked outputs and governance.
- [Machine Learning Architecture](https://banes-lab.com/records/architecture/machine-learning-architecture.md): A conceptual representation of a model's lifecycle as versioned data, feature, training, evaluation and serving stages.
- [Model Governance](https://banes-lab.com/records/architecture/model-governance.md): The activity of registering, evaluating and approving each model version before it is deployed.
- [Model Evaluation](https://banes-lab.com/records/architecture/model-evaluation.md): The activity of measuring a model against datasets, metrics and slices, and comparing the results with acceptance thresholds.
- [Model Inference](https://banes-lab.com/records/architecture/model-inference.md): The ability to run a trained model on validated input at runtime and return a checked prediction or generation.
- [Retrieval-Augmented Generation (RAG)](https://banes-lab.com/records/architecture/retrieval-augmented-generation.md): A design pattern that retrieves relevant documents for a question and passes them to the model, so the answer can cite its sources.
- [Vector Search](https://banes-lab.com/records/architecture/vector-search.md): A mechanism that finds records whose embeddings lie close to a query's embedding.
- [Knowledge Graphs](https://banes-lab.com/records/architecture/knowledge-graphs.md): A design pattern that stores knowledge as typed entities and named relations, validated against a schema, so queries can traverse them.
- [Explainability](https://banes-lab.com/records/architecture/explainability.md): The degree to which a model's decision comes with the evidence or attribution a reviewer needs to understand it.
- [Model Safety](https://banes-lab.com/records/architecture/model-safety.md): The degree to which a model-backed system prevents harmful inputs, outputs and actions through evaluation, guardrails and monitoring.
- [Prompt Engineering](https://banes-lab.com/records/architecture/prompt-engineering.md): A technique for writing model instructions as versioned templates with fixed parameters and an evaluation for each change.
- [Model Drift Monitoring](https://banes-lab.com/records/architecture/model-drift-monitoring.md): The activity of tracking a deployed model's inputs and output quality over time and alerting when they move past a threshold.
- [Agentic Architecture](https://banes-lab.com/records/architecture/agentic-architecture.md): A design pattern in which the model chooses actions from a scoped set of tools, within a step limit and under review.
- [Observability](https://banes-lab.com/records/architecture/observability.md): The degree to which a system's internal behavior in production can be inferred from the logs, metrics and traces it emits.
- [Logging](https://banes-lab.com/records/architecture/logging.md): A mechanism that records structured events with their context as the code runs.
- [Monitoring](https://banes-lab.com/records/architecture/monitoring.md): A mechanism that collects metrics about resources and service levels over time and compares them with thresholds.
- [Alerting](https://banes-lab.com/records/architecture/alerting.md): A mechanism that notifies an on-call responder when a monitored condition holds for longer than its threshold.
- [Auditability](https://banes-lab.com/records/architecture/auditability.md): The degree to which each sensitive action can be traced afterwards to its actor, target, time and reason.
- [Audit Logging](https://banes-lab.com/records/architecture/audit-logging.md): A mechanism that appends an immutable record of each sensitive operation, naming the actor, the action, the target and the time.
- [Traceability](https://banes-lab.com/records/architecture/traceability.md): The degree to which a request, workflow or change can be followed end to end through correlated records.
- [Correlation ID](https://banes-lab.com/records/architecture/correlation-id.md): A mechanism that attaches one identifier to a request and carries it through every call, message and log line the request causes.
- [Causation ID](https://banes-lab.com/records/architecture/causation-id.md): A mechanism that stamps each event with the identifier of the event that caused it.
- [Distributed Tracing](https://banes-lab.com/records/architecture/distributed-tracing.md): A mechanism that propagates a trace context across service calls and records each call as a timed span of one trace.
- [SLO/SLI](https://banes-lab.com/records/architecture/slo-sli.md): A rule or precondition that a service's reliability is stated as a measured indicator with an objective and an error budget over a window.
- [Dashboards](https://banes-lab.com/records/architecture/dashboards.md): Descriptive data about a system's key signals, arranged as panels that show health and trends at a glance.
- [Strategy Pattern](https://banes-lab.com/records/architecture/strategy-pattern.md): A design pattern that puts each interchangeable algorithm behind one interface, so the caller selects behavior by passing an object.
- [Template Method Pattern](https://banes-lab.com/records/architecture/template-method-pattern.md): A design pattern that fixes the steps of an algorithm in a base class and lets subclasses supply the steps that vary.
- [Observer Pattern](https://banes-lab.com/records/architecture/observer-pattern.md): A design pattern in which a subject publishes events to subscribers it does not know by name.
- [Mediator Pattern](https://banes-lab.com/records/architecture/mediator-pattern.md): A design pattern that routes the interactions between a set of objects through one coordinating object.
- [Command Pattern](https://banes-lab.com/records/architecture/command-pattern.md): A design pattern that wraps a request in an object, so it can be queued, deferred or undone.
- [State Pattern](https://banes-lab.com/records/architecture/state-pattern.md): A design pattern that gives each state of an object its own class, so behavior and legal transitions change with the state.
- [Chain of Responsibility Pattern](https://banes-lab.com/records/architecture/chain-of-responsibility-pattern.md): A design pattern that passes a request along an ordered list of handlers until one of them handles it.
- [Iterator Pattern](https://banes-lab.com/records/architecture/iterator-pattern.md): A design pattern that lets callers traverse a collection without seeing how it is stored.
- [Visitor Pattern](https://banes-lab.com/records/architecture/visitor-pattern.md): A design pattern that places each operation over a type hierarchy in its own visitor, so an operation is added without editing the element types.
- [Memento Pattern](https://banes-lab.com/records/architecture/memento-pattern.md): A design pattern in which an object captures its own state in an opaque snapshot it can later restore.
- [Null Object Pattern](https://banes-lab.com/records/architecture/null-object-pattern.md): A design pattern that represents absence with an object implementing the expected interface as a no-op.
- [Finite State Machine](https://banes-lab.com/records/architecture/finite-state-machine.md): A conceptual representation of behavior as a closed set of states and the events that move between them.
- [Statecharts](https://banes-lab.com/records/architecture/statecharts.md): A conceptual representation of a state machine extended with nested states and parallel regions.
- [Factory Pattern](https://banes-lab.com/records/architecture/factory-pattern.md): A design pattern that moves the construction of an object and its defaults into one function or object.
- [Factory Method Pattern](https://banes-lab.com/records/architecture/factory-method-pattern.md): A design pattern in which a base class calls an overridable method to create the objects its workflow uses.
- [Abstract Factory Pattern](https://banes-lab.com/records/architecture/abstract-factory-pattern.md): A design pattern that creates a whole family of related objects through one interface, so the members always match.
- [Builder Pattern](https://banes-lab.com/records/architecture/builder-pattern.md): A design pattern that assembles a complex object step by step through named calls and validates it when it is built.
- [Prototype Pattern](https://banes-lab.com/records/architecture/prototype-pattern.md): A design pattern that creates new objects by cloning a prepared template and applying overrides.
- [Singleton Pattern](https://banes-lab.com/records/architecture/singleton-pattern.md): A design pattern that restricts a class to one instance, reached through a global access point.
- [Adapter Pattern](https://banes-lab.com/records/architecture/adapter-pattern.md): A design pattern that wraps a component with an incompatible interface so it implements the interface its callers expect.
- [Facade Pattern](https://banes-lab.com/records/architecture/facade-pattern.md): A design pattern that gives a subsystem one simple entry point, so callers do not depend on its parts.
- [Proxy Pattern](https://banes-lab.com/records/architecture/proxy-pattern.md): A design pattern that places a stand-in with the same interface in front of an object, to control, defer or cache access to it.
- [Bridge Pattern](https://banes-lab.com/records/architecture/bridge-pattern.md): A design pattern that separates two independent axes of variation into two hierarchies joined by composition.
- [Decorator Pattern](https://banes-lab.com/records/architecture/decorator-pattern.md): A design pattern that adds behavior to an object by wrapping it in another object with the same interface.
- [Composite Pattern](https://banes-lab.com/records/architecture/composite-pattern.md): A design pattern that gives leaves and groups one interface, so a tree is traversed without checking which kind each node is.
- [Flyweight Pattern](https://banes-lab.com/records/architecture/flyweight-pattern.md): A design pattern that shares one copy of immutable intrinsic state among many objects, each keeping only its own extrinsic state.
- [Scalability](https://banes-lab.com/records/architecture/scalability.md): The degree to which a system keeps its throughput and latency as load grows, by adding resources.
- [Horizontal Scaling](https://banes-lab.com/records/architecture/horizontal-scaling.md): A technique for adding capacity by running more stateless instances of a service behind a load balancer.
- [Vertical Scaling](https://banes-lab.com/records/architecture/vertical-scaling.md): A technique for adding capacity by giving one instance more CPU, memory or I/O.
- [Elasticity](https://banes-lab.com/records/architecture/elasticity.md): The degree to which a system's provisioned capacity follows demand up and down automatically.
- [Load Balancing](https://banes-lab.com/records/architecture/load-balancing.md): A mechanism that spreads incoming requests across healthy instances of a service.
- [Sharding](https://banes-lab.com/records/architecture/sharding.md): A design pattern that splits a dataset across separate stores by a shard key, and routes each request to the shard that holds its key.
- [Partitioning](https://banes-lab.com/records/architecture/partitioning.md): A technique for dividing data or work into independent partitions by a key, so each can be processed in parallel.
- [Caching](https://banes-lab.com/records/architecture/caching.md): A design pattern that stores the result of an expensive read or computation under a key derived from every input it depends on, and serves it again while that key matches.
- [Statelessness](https://banes-lab.com/records/architecture/statelessness.md): A design rule that a handler keeps no request state between calls, so any instance can serve any request.
- [Concurrency](https://banes-lab.com/records/architecture/concurrency.md): A conceptual representation of several tasks in progress over overlapping time, with their access to shared state coordinated.
- [Parallelism](https://banes-lab.com/records/architecture/parallelism.md): A technique for running independent units of work at the same time on several cores or workers.
- [Throughput](https://banes-lab.com/records/architecture/throughput.md): The rate at which a system completes requests, messages or items, counted per unit of time.
- [Latency](https://banes-lab.com/records/architecture/latency.md): A measure of the time between a request and its response, usually reported at percentiles.
- [Performance Engineering](https://banes-lab.com/records/architecture/performance-engineering.md): The practice of setting performance budgets, measuring against a representative workload and changing code only where a measurement points.
- [Algorithmic Efficiency](https://banes-lab.com/records/architecture/algorithmic-efficiency.md): A design rule that an algorithm and its data structures are chosen for how their cost grows with input size.
- [Time Complexity](https://banes-lab.com/records/architecture/time-complexity.md): A measure of how an algorithm's running time grows as its input grows.
- [Space Complexity](https://banes-lab.com/records/architecture/space-complexity.md): A measure of how an algorithm's memory use grows as its input grows.
- [Big O Notation](https://banes-lab.com/records/architecture/big-o-notation.md): A method for classifying an algorithm by the upper bound on how its cost grows with input size, ignoring constant factors.
- [Optimization](https://banes-lab.com/records/architecture/optimization.md): The activity of changing code or configuration to reduce the cost of a bottleneck that a measurement has located.
- [Profiling](https://banes-lab.com/records/architecture/profiling.md): A technique for measuring where a running program spends its time and memory under a representative workload.
- [Benchmarking](https://banes-lab.com/records/architecture/benchmarking.md): The activity of timing a fixed workload repeatedly in a controlled environment, so results can be compared across changes.
- [Bottleneck Analysis](https://banes-lab.com/records/architecture/bottleneck-analysis.md): The activity of finding the stage that limits a system's overall throughput or latency, from traces and profiles.
- [Resource Utilization](https://banes-lab.com/records/architecture/resource-utilization.md): A measure of how much of the provisioned CPU, memory, I/O and network capacity is in use.
- [Rate Limiting](https://banes-lab.com/records/architecture/rate-limiting.md): A mechanism that caps how many requests a caller can make in a time window and rejects the excess.
- [Memory Efficiency](https://banes-lab.com/records/architecture/memory-efficiency.md): The degree to which a process handles its input with bounded memory, by streaming or chunking instead of loading it whole.
- [CDN / Edge Caching](https://banes-lab.com/records/architecture/cdn-edge-caching.md): A mechanism that serves cacheable content from servers near the requester, keyed by a fingerprint of the content.
- [Read Replica](https://banes-lab.com/records/architecture/read-replica.md): A technique for routing read queries to replicated copies of a database, so the primary handles only writes.
- [Queuing Theory](https://banes-lab.com/records/architecture/queuing-theory.md): A conceptual representation of a system as queues with arrival and service rates, used to predict waiting time and size capacity.
- [Streaming Architecture](https://banes-lab.com/records/architecture/streaming-architecture.md): A convention of processing data record by record as it arrives, with backpressure, instead of collecting it first.
- [Single-Pass Processing](https://banes-lab.com/records/architecture/single-pass-processing.md): A design rule that large input is read once, with every result it feeds computed in that one pass.
- [Pipeline Architecture](https://banes-lab.com/records/architecture/pipeline-architecture.md): A design pattern that splits processing into ordered stages, each with a declared input and output contract.
- [Lazy Evaluation](https://banes-lab.com/records/architecture/lazy-evaluation.md): An approach in which a value is computed only when something consumes it.
- [Sequential Access](https://banes-lab.com/records/architecture/sequential-access.md): A design pattern that reads a source in its stored order through a cursor or scan, instead of looking records up one by one.
- [Forward-Only Processing](https://banes-lab.com/records/architecture/forward-only-processing.md): A rule or precondition that a stream is read once in order, keeping only rolling state, so no decision ever needs to revisit earlier input.
- [Dataflow Architecture](https://banes-lab.com/records/architecture/dataflow-architecture.md): A convention of arranging processing as a graph of stages connected by explicit data edges, where a stage runs when its inputs arrive.
- [Stateless Processing](https://banes-lab.com/records/architecture/stateless-processing.md): A design rule that a processor derives each result only from its input and explicitly passed context.
- [Windowing](https://banes-lab.com/records/architecture/windowing.md): A mechanism that groups an unbounded stream into bounded windows of event time and aggregates each window separately.
- [Fan-out/Fan-in](https://banes-lab.com/records/architecture/fan-out-fan-in.md): A design pattern that splits work into independent parts processed in parallel, then merges their results.
- [Batch-vs-Stream](https://banes-lab.com/records/architecture/batch-vs-stream.md): An approach in which the processing model, periodic batch or continuous stream, is chosen by how fresh the data must be.
- [Plugin Architecture](https://banes-lab.com/records/architecture/plugin-architecture.md): A convention of building a small core that discovers and loads plugins through declared extension points.
- [Extension Points](https://banes-lab.com/records/architecture/extension-points.md): A mechanism that exposes named hooks or interfaces where new behavior can be added without editing the core.
- [Inversion of Control (IoC)](https://banes-lab.com/records/architecture/inversion-of-control.md): A design rule that a framework or composition root owns object creation and control flow, and application code supplies the parts it calls.
- [Dependency Injection](https://banes-lab.com/records/architecture/dependency-injection.md): A design pattern that passes an object its dependencies from outside, usually through its constructor.
- [Service Registry](https://banes-lab.com/records/architecture/service-registry.md): A mechanism where services or plugins register under a key and are resolved by that key at runtime.
- [Registry Pattern](https://banes-lab.com/records/architecture/registry-pattern.md): A design pattern that replaces a conditional over kinds with a keyed table that each kind registers itself into.
- [Service Locator Pattern](https://banes-lab.com/records/architecture/service-locator-pattern.md): A design pattern in which code fetches its dependencies from a global registry at the point of use.
- [Feature Toggle](https://banes-lab.com/records/architecture/feature-toggle.md): A mechanism that switches a code path on or off at runtime from externally held flag state, so a release can happen without a deploy.
- [Self-Healing Architecture](https://banes-lab.com/records/architecture/self-healing-architecture.md): The ability of a system to detect a failed component from its health signals and restore it without human action.
- [Health Checks](https://banes-lab.com/records/architecture/health-checks.md): A mechanism that reports whether an instance and the dependencies it needs are ready to serve, so routing and restarts can act on it.
- [Failover](https://banes-lab.com/records/architecture/failover.md): A mechanism that switches traffic or reads to a standby instance when the active one fails.
- [Redundancy](https://banes-lab.com/records/architecture/redundancy.md): A mechanism that keeps spare instances or capacity for a critical component, spread across failure domains.
- [Replication](https://banes-lab.com/records/architecture/replication.md): A mechanism that keeps copies of data on several nodes under a declared consistency policy, such as a write quorum.
- [Auto-Scaling](https://banes-lab.com/records/architecture/auto-scaling.md): The ability to change the number of running instances automatically, between set bounds, from a load metric.
- [Auto-Remediation](https://banes-lab.com/records/architecture/auto-remediation.md): The ability to run a guarded, automated response, such as a restart, a reset and replay or a compaction, when an alert or a health signal shows a failure whose fix is known.
- [Rollback](https://banes-lab.com/records/architecture/rollback.md): A mechanism that restores the previous versioned release when a deployment fails its verification.
- [Blue-Green Deployment](https://banes-lab.com/records/architecture/blue-green-deployment.md): A design pattern that deploys a release to an idle copy of production, verifies it, and switches traffic to it at once.
- [Canary Deployment](https://banes-lab.com/records/architecture/canary-deployment.md): A design pattern that sends a small share of traffic to a new release and widens the share only while its error and latency stay within limits.
- [Chaos Engineering](https://banes-lab.com/records/architecture/chaos-engineering.md): The practice of injecting controlled faults into a running system to test a stated hypothesis about how it recovers.
- [Graceful Shutdown](https://banes-lab.com/records/architecture/graceful-shutdown.md): A mechanism that, on a stop signal, stops accepting work, drains in-flight work and closes connections before the process exits.
- [RAID Redundancy](https://banes-lab.com/records/architecture/raid-redundancy.md): A technique for spreading data across several disks with mirroring or parity, so the loss of a disk loses no data.
- [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md): A mechanism that parses incoming data against a schema at the boundary and rejects any payload that does not conform.
- [Type Safety](https://banes-lab.com/records/architecture/type-safety.md): A mechanism that has the compiler reject operations on values of the wrong type before the code runs.
- [Canonical Model](https://banes-lab.com/records/architecture/canonical-model.md): A design rule that a concept has one authoritative representation, and every other representation is translated to and from it.
- [Canonical Data Model](https://banes-lab.com/records/architecture/canonical-data-model.md): A design pattern in which integrated systems exchange data through one shared model, with a mapping per system.
- [Canonical Schema](https://banes-lab.com/records/architecture/canonical-schema.md): A formal definition of one concept's shape, published once and used by every API, message and store that carries the concept.
- [Canonicalization](https://banes-lab.com/records/architecture/canonicalization.md): A technique for converting equivalent values to one normal form before they are compared, stored or checked.
- [Single Source of Truth](https://banes-lab.com/records/architecture/single-source-of-truth.md): A design rule that each fact, rule or configuration value has one owning definition, and every other value is derived from it.
- [Normalization](https://banes-lab.com/records/architecture/normalization.md): A technique for storing each fact once and referring to it by key wherever it is needed.
- [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md): The degree to which one name carries one meaning across the code, the schemas and the documentation.
- [Ubiquitous Language](https://banes-lab.com/records/architecture/ubiquitous-language.md): The practice of using the domain's own terms, agreed with its experts, in conversation, documentation and code alike.
- [Intent-Revealing Interface](https://banes-lab.com/records/architecture/intent-revealing-interface.md): A design rule that an operation's name and parameters state what it does for the caller.
- [Principle of Least Surprise](https://banes-lab.com/records/architecture/principle-of-least-surprise.md): A design rule that an operation behaves the way its name and its conventions lead a caller to expect.
- [Database Normalization](https://banes-lab.com/records/architecture/database-normalization.md): A technique for decomposing tables by their functional dependencies into normal forms, so no column depends on anything but its key.
- [Security by Design](https://banes-lab.com/records/architecture/security-by-design.md): A design rule that threats are modeled and controls built into every component from its first design.
- [Defense in Depth](https://banes-lab.com/records/architecture/defense-in-depth.md): A design rule that several independent security controls protect each asset, so one failed control does not expose it.
- [Least Privilege](https://banes-lab.com/records/architecture/least-privilege.md): A design rule that each user, service and process holds only the permissions its task needs.
- [Zero Trust Architecture](https://banes-lab.com/records/architecture/zero-trust-architecture.md): A convention of authenticating and authorizing every request on its own identity and context, whatever network it comes from.
- [Secure by Default](https://banes-lab.com/records/architecture/secure-by-default.md): A design rule that every setting ships in its most restrictive safe state, and weakening one requires an explicit opt-in.
- [Attack Surface Reduction](https://banes-lab.com/records/architecture/attack-surface-reduction.md): A design rule that endpoints, ports, features and permissions nothing uses are removed or disabled.
- [Threat Modeling](https://banes-lab.com/records/architecture/threat-modeling.md): The activity of listing a flow's assets, trust boundaries and threats, and choosing a mitigation for each threat.
- [Authentication](https://banes-lab.com/records/architecture/authentication.md): A mechanism that verifies a caller's claimed identity from a credential before any protected action runs.
- [Authorization](https://banes-lab.com/records/architecture/authorization.md): A mechanism that decides, from a policy, whether an authenticated principal may perform an action on a resource.
- [Access Control](https://banes-lab.com/records/architecture/access-control.md): A mechanism that evaluates an access policy for each request to a resource and denies the request when the policy does not allow it.
- [RBAC](https://banes-lab.com/records/architecture/role-based-access-control.md): A conceptual representation of access control, Role-Based Access Control (RBAC), in which permissions attach to roles and users receive roles.
- [ABAC](https://banes-lab.com/records/architecture/attribute-based-access-control.md): A conceptual representation of access control, Attribute-Based Access Control (ABAC), in which a policy decides from attributes of the subject, the resource and the environment.
- [Input Validation](https://banes-lab.com/records/architecture/input-validation.md): A mechanism that checks external input against a schema at the boundary before core logic uses it.
- [Output Encoding](https://banes-lab.com/records/architecture/output-encoding.md): A mechanism that escapes values for the context they are written into, such as HTML, SQL or a shell.
- [Encryption at Rest](https://banes-lab.com/records/architecture/encryption-at-rest.md): A mechanism that encrypts stored data with managed keys, so the storage medium alone does not reveal it.
- [Encryption in Transit](https://banes-lab.com/records/architecture/encryption-in-transit.md): A mechanism that encrypts traffic between parties with TLS or mutual TLS and verifies the peer's certificate.
- [Secrets Management](https://banes-lab.com/records/architecture/secrets-management.md): The practice of keeping credentials in a secret store, reading them at runtime and rotating them on a schedule.
- [Privacy by Design](https://banes-lab.com/records/architecture/privacy-by-design.md): A design rule that privacy protection is part of a system's design from its first version, covering which personal data it collects, how long it keeps it, who can see it and what its defaults expose.
- [Compliance](https://banes-lab.com/records/architecture/compliance.md): A rule or precondition that a system implements the controls a regulation or standard requires, and keeps evidence of each one.
- [Governance](https://banes-lab.com/records/architecture/governance.md): A design rule that architecture decisions are held to stated policies and standards, through review and automated gates.
- [Policy Enforcement](https://banes-lab.com/records/architecture/policy-enforcement.md): A mechanism that blocks an action a policy forbids at the point the action is attempted.
- [Policy as Code](https://banes-lab.com/records/architecture/policy-as-code.md): A mechanism that expresses policies as machine-readable rules which a pipeline or policy engine evaluates automatically.
- [Risk Management](https://banes-lab.com/records/architecture/risk-management.md): The activity of identifying risks, rating their likelihood and impact, and assigning each one an owner and a mitigation.
- [Continuous Compliance](https://banes-lab.com/records/architecture/continuous-compliance.md): The ability to check compliance on every change, with automated policy gates and evidence capture.
- [CSRF Protection](https://banes-lab.com/records/architecture/csrf-protection.md): A mechanism that rejects state-changing requests which lack proof of coming from the site's own pages, such as an anti-forgery token.
- [Parameterized Queries](https://banes-lab.com/records/architecture/parameterized-queries.md): A mechanism that sends query text and values to the database separately, so values are never parsed as query syntax.
- [Session Management](https://banes-lab.com/records/architecture/session-management.md): A mechanism that keeps authenticated sessions on the server, with expiry, rotation and revocation, and gives the client only an opaque identifier.
- [Ports and Adapters Architecture](https://banes-lab.com/records/architecture/ports-and-adapters-architecture.md): A convention of placing every external dependency behind a port the application owns, implemented by an adapter outside it.
- [Hexagonal Architecture](https://banes-lab.com/records/architecture/hexagonal-architecture.md): A convention of keeping a domain core free of framework and data types, with every input and output reached through ports.
- [Clean Architecture](https://banes-lab.com/records/architecture/clean-architecture.md): A convention of concentric layers in which source dependencies point only inward, towards the use cases and entities.
- [Layered Architecture](https://banes-lab.com/records/architecture/layered-architecture.md): A convention of stacking presentation, application and persistence layers, each calling only the layer below it.
- [Component-Based Architecture](https://banes-lab.com/records/architecture/component-based-architecture.md): A convention of building a system from components that declare what they export and what they require.
- [Package by Feature](https://banes-lab.com/records/architecture/package-by-feature.md): A design rule that code is grouped by the feature it serves, so one change stays inside one package.
- [Microservices](https://banes-lab.com/records/architecture/microservices.md): A convention of splitting a system into services that each own their data and deploy independently.
- [Monolith Architecture](https://banes-lab.com/records/architecture/monolith-architecture.md): A convention of deploying a system as one unit, with its modules kept apart by internal boundaries.
- [Pipes and Filters](https://banes-lab.com/records/architecture/pipes-and-filters.md): A convention of processing data through independent stages that share one input and output interface.
- [Service-Oriented Architecture](https://banes-lab.com/records/architecture/service-oriented-architecture.md): A convention of exposing each business capability as a service governed by a published contract.
- [Space-Based Architecture](https://banes-lab.com/records/architecture/space-based-architecture.md): A convention of holding working state in a replicated in-memory space, so no central database limits scaling.
- [Stated Invariant](https://banes-lab.com/records/architecture/stated-invariant.md): A design rule that an invariant a topology relies on is written with its property in a form that could be false, the set it ranges over, the parties it binds and the thing that would object if it stopped holding.
- [Derived Record State](https://banes-lab.com/records/architecture/derived-record-state.md): A design rule that a record's state is a query over the edges it carries, open while its satisfying artifact is unresolved, blocked while a blocker is open and absorbed once the artifact exists, so no party writes a state.
- [Declared Subject](https://banes-lab.com/records/architecture/declared-subject.md): A rule or precondition that a record carries an allocated id and a declared subject key as two fields, so a moved surface keeps the id, a renamed subject keeps the key, and two records sharing a key are a finding.
- [Write Barrier](https://banes-lab.com/records/architecture/write-barrier.md): A mechanism that lets a planned exclusive write to a shared surface proceed only once every peer is observed parked, beside a compare-and-swap that covers every other write.
- [Operand-Free Outcome Surface](https://banes-lab.com/records/architecture/operand-free-outcome-surface.md): A rule or precondition that a surface carrying one jointly authored product declares that one writer per record has no operand there, and settles a collision by announcement and by each author cutting its own duplicate.
- [Projection Channel](https://banes-lab.com/records/architecture/projection-channel.md): A rule or precondition that the projection a host injects into every bounded reader is refreshed in the same change as the fact it carries, in a shape a check reads.
- [Two-Direction Index](https://banes-lab.com/records/architecture/two-direction-index.md): A mechanism that generates an index from the directory on every run and checks it both ways, reporting an entry with no file and a file with no entry, with every scan independent of depth.
- [Independent Lifetime Axes](https://banes-lab.com/records/architecture/independent-lifetime-axes.md): A design rule that a surface's lifetime is declared on three independent axes, retention, mutability and removal authority, each taking a value from a closed set, so no single word stands for all three.
- [Section Lifetime Divergence](https://banes-lab.com/records/architecture/section-lifetime-divergence.md): A rule or precondition that a file states a default lifetime and each section declares only the axes on which it differs, since the narrower unit is the more constrained one.
- [Write Scope and Read Population](https://banes-lab.com/records/architecture/write-scope-and-read-population.md): A design rule that a run declares the paths it writes and publishes the set it read as two declarations, because collision is decided by the first and a published result's validity by the second.
- [Read-Time Join](https://banes-lab.com/records/architecture/read-time-join.md): A mechanism that lets a caller whose question a live declared scope already covers read that run's published result and its standing, writing nothing, so it cannot deadlock, be orphaned or need cleanup.
- [One-Sided Liveness](https://banes-lab.com/records/architecture/one-sided-liveness.md): A design rule that a process's absence proves it is dead while its presence proves nothing, so liveness is derived once, from the witness first and from a generous window only where the witness cannot decide.
- [Reversible Channel Encoding](https://banes-lab.com/records/architecture/reversible-channel-encoding.md): A rule or precondition that a channel name is a total and invertible encoding of the scope it belongs to, with an alphabet that excludes the separator, so a retention check can read the scope back out of the name.
- [Declare-Before-Read Order](https://banes-lab.com/records/architecture/declare-before-read-order.md): A mechanism that orders two simultaneous starters without a lock by writing each entry before reading the set, with the start stamp and then the party identity breaking a tie.
- [Period-Decided Disposition](https://banes-lab.com/records/architecture/period-decided-disposition.md): A design rule that a duplicate is first counted by its distinguished copies and then read by the period of each derivation edge, so a periodic copy owes a comparator and a one-shot copy is a record whose source is repaired instead.
- [Derived Party Count](https://banes-lab.com/records/architecture/derived-party-count.md): A design rule that the number of parties a body of work implies is derived from how the work is partitioned into concerns, so two parties holding one partition reach one count.
- [Fan-In Ceiling](https://banes-lab.com/records/architecture/fan-in-ceiling.md): A rule or precondition that the useful number of parties is bounded by the fan-in of the most contended surface, where claims resting on it go stale faster than they help.
- [State-Arity Limit](https://banes-lab.com/records/architecture/state-arity-limit.md): A rule or precondition that a property relating two states of content, such as growing but never shrinking, is enforced only by a mechanism holding both readings, in the layer that already spans runs.
- [Carrier and Payload Split](https://banes-lab.com/records/architecture/carrier-and-payload-split.md): A design rule that a surface read through a tool types the fields a mechanism joins on and leaves the fields only a reader consumes as prose, deciding the line per field.
- [Joinable Mandated Field](https://banes-lab.com/records/architecture/joinable-mandated-field.md): A rule or precondition that a mandated field takes a value from a closed set or an identifier, or declares that it is written for readers, so a governed surface never looks measured on a property nothing can read.
- [Single Aggregate](https://banes-lab.com/records/architecture/single-aggregate.md): A rule or precondition that a shared measurement keeps one aggregate, overwritten by each run that can honestly replace it, while a run that cannot streams its verdict instead of writing a second report.
- [Contradicted Invariant](https://banes-lab.com/records/architecture/contradicted-invariant.md): A defect in which one surface states the opposite of an invariant another relies on, so every mechanism faithfully implementing either statement stays green while the invariant is violated.
- [Written Status Marker](https://banes-lab.com/records/architecture/written-status-marker.md): A defect in which a party writes a record's state as a marker instead of deriving it from the record's edges, so the marker goes stale and asserts a state that no longer holds.
- [Invocation-Keyed Report](https://banes-lab.com/records/architecture/invocation-keyed-report.md): A defect in which a run writes its result under a name derived from how it was invoked, beside the shared aggregate, so documents accumulate that each describe a moment and none the state.
- [Narrowed Aggregate](https://banes-lab.com/records/architecture/narrowed-aggregate.md): A defect in which a run over a narrowed scope overwrites the whole-scope aggregate, so the aggregate reports a smaller population as though it were the whole.
- [Cyclic Tiebreak](https://banes-lab.com/records/architecture/cyclic-tiebreak.md): A defect in which a tiebreak picks a source among copies none of which is distinguished, turning a correct refusal into a direction no copy supports.
- [Destructive Closure](https://banes-lab.com/records/architecture/destructive-closure.md): A defect in which closing a converged venue deletes it instead of moving it to the archive, keeping the outcome and destroying the argument it came from.
- [Hand-Kept Index](https://banes-lab.com/records/architecture/hand-kept-index.md): A defect in which an index is written by hand beside what it indexes, so it drifts silently because nothing compares the two.
- [Closed Vocabulary](https://banes-lab.com/records/architecture/closed-vocabulary.md): A design rule that every word in a name slot comes from a declared list, and a new word enters the list only by an approved edit.
- [Positional Slot Resolution](https://banes-lab.com/records/architecture/positional-slot-resolution.md): A mechanism that reads each word of a path by the slot it lands in, so the last dot-segment before a file's extension is always its concern and a folder named after a concern tag resolves as the latest role its depth can legally take.
- [Concern-Folder Correspondence](https://banes-lab.com/records/architecture/concern-folder-correspondence.md): A rule or precondition that a file's concern tag matches the label of the folder that holds it.
- [Glob-Resolvable Tree](https://banes-lab.com/records/architecture/glob-resolvable-tree.md): A mechanism that lets one unanchored pattern per concern collect every matching file or folder, at whatever depth it sits.
- [Declared Jurisdiction](https://banes-lab.com/records/architecture/declared-jurisdiction.md): A design rule that a naming gate reads from one declaration the roots it governs, the containers and buckets under each, the classes of file exempt from the grammar, and the trees another system authors or resolves by name, which are exempted once and never governed.
- [Bounded Nesting Depth](https://banes-lab.com/records/architecture/bounded-nesting-depth.md): A rule or precondition that a file sits within a fixed number of folders below its governed root, with each folder taking a later role than the one above it.
- [Sideways Overflow](https://banes-lab.com/records/architecture/sideways-overflow.md): A design pattern that resolves a naming collision with the filename's variant slot and resolves breadth with a sibling subject folder.
- [One Concern Per File](https://banes-lab.com/records/architecture/one-concern-per-file.md): A design rule that each file plays exactly one declared role, and a file that plays two is split.
- [Narrowest Concern](https://banes-lab.com/records/architecture/narrowest-concern.md): A design rule that a file is classified under the narrowest declared role that describes it accurately.
- [Layer Spine Precedence](https://banes-lab.com/records/architecture/layer-spine-precedence.md): A mechanism that breaks an irreducible tie between two roles in favor of the one nearer the domain on the layer spine.
- [Agnostic-First Vocabulary](https://banes-lab.com/records/architecture/agnostic-first-vocabulary.md): A design rule that a domain-specific role word is admitted only where no domain-neutral role already covers it.
- [Guided Vocabulary Refusal](https://banes-lab.com/records/architecture/guided-vocabulary-refusal.md): A mechanism that answers a refused word with the declared word that covers its role, looked up in an indexed rejection table.
- [Derived Naming Registry](https://banes-lab.com/records/architecture/derived-naming-registry.md): Descriptive data about the declared vocabulary and roots, derived from the naming document so a gate can read it, with the reasoning kept in the document.
- [Set-Relative Member Name](https://banes-lab.com/records/architecture/set-relative-member-name.md): A rule or precondition that a file inside a subject folder names only its own subject, because the folder already names the set.
- [Manual Identity Migration](https://banes-lab.com/records/architecture/manual-identity-migration.md): A technique for renaming files one container at a time by hand, re-pointing each pattern and comparing what each aggregator collects before and after.
- [Collision Consolidation](https://banes-lab.com/records/architecture/collision-consolidation.md): A design rule that a filename already held by another file is first read as a sign that both files do the same job, and a variant is added only after the code shows that their jobs differ.
- [Mirrored Test Placement](https://banes-lab.com/records/architecture/mirrored-test-placement.md): A rule or precondition that a test sits in the concern folder of the file it tests, under a test root mirroring that file's governed root, and moves whenever that file moves.
- [Sanctioned Generic Subject](https://banes-lab.com/records/architecture/sanctioned-generic-subject.md): A rule or precondition that a file takes the one generic subject only when it is generic over its type parameters and names no domain noun anywhere in its source.
- [Conformance at Creation](https://banes-lab.com/records/architecture/conformance-at-creation.md): A design rule that a file created under a governed root is named and placed correctly when it is first written, so no conversion queue accumulates behind new work.
- [Registry-Held Order](https://banes-lab.com/records/architecture/registry-held-order.md): A design rule that load or execution order is held by an import list or a registry, so a filename carries no numeric prefix the grammar would have to parse.
- [Externally Resolved Slot](https://banes-lab.com/records/architecture/externally-resolved-slot.md): A mechanism that resolves a name slot whose words another source owns against that source, whether an index that allocates identities, an upstream key set or a field the file itself carries, so the closed vocabulary never holds a copy of them.
- [Case Dialect](https://banes-lab.com/records/architecture/case-dialect.md): A mechanism that binds file extensions to the case their language names files in and reads the same subject, variant and concern slots from the stem's word boundaries.
- [Root Spine Files](https://banes-lab.com/records/architecture/root-spine-files.md): A rule or precondition that a governed root carries only its entry document and its accumulators at the root, and every other file sits in a concern folder.
- [Idempotency](https://banes-lab.com/records/architecture/idempotency.md): A design rule that repeating an operation with the same input has the same effect as running it once.
- [Atomicity](https://banes-lab.com/records/architecture/atomicity.md): A design rule that the steps of a state change either all take effect or none do.
- [ACID](https://banes-lab.com/records/architecture/acid.md): A conceptual representation of the four guarantees of a database transaction: atomicity, consistency, isolation and durability.
- [Transaction Boundary](https://banes-lab.com/records/architecture/transaction-boundary.md): A rule or precondition that a transaction covers exactly the writes of one unit of work inside one service.
- [Unit of Work Pattern](https://banes-lab.com/records/architecture/unit-of-work-pattern.md): A design pattern that collects the changes of one use case and commits them together in a single transaction.
- [Consistency](https://banes-lab.com/records/architecture/consistency.md): The degree to which stored data satisfies its invariants after every change.
- [Isolation](https://banes-lab.com/records/architecture/isolation.md): A rule or precondition that concurrent transactions do not see each other's uncommitted changes, to the degree the isolation level declares.
- [Concurrency Control](https://banes-lab.com/records/architecture/concurrency-control.md): A mechanism that coordinates concurrent access to shared state, through locks, versions or compare-and-swap.
- [Optimistic Locking](https://banes-lab.com/records/architecture/optimistic-locking.md): A design pattern that checks a record's version when it is written and rejects the write if another writer changed it first, comparing only the writer's own span where a surface is fenced per writer.
- [Pessimistic Locking](https://banes-lab.com/records/architecture/pessimistic-locking.md): A design pattern that locks a record before reading it for update, so other writers wait until the transaction ends.
- [State Isolation](https://banes-lab.com/records/architecture/state-isolation.md): A design rule that each piece of mutable state belongs to one unit of concurrent execution, so no two units that run at the same time can write it.
- [Controlled Side Effects](https://banes-lab.com/records/architecture/controlled-side-effects.md): A design rule that mutation, I/O and persistence happen at declared boundaries, around a core of pure functions.
- [Petri Nets](https://banes-lab.com/records/architecture/petri-nets.md): A conceptual representation of concurrent flow as places holding tokens and transitions that consume and produce them, which can be analyzed for deadlock.