# The lex face

> 1357 records.

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

## Fields

- `kind`: [activity](https://banes-lab.com/api/facets/lex/kind/activity.md) (34), [anti-pattern](https://banes-lab.com/api/facets/lex/kind/anti-pattern.md) (314), [approach](https://banes-lab.com/api/facets/lex/kind/approach.md) (13), [artifact](https://banes-lab.com/api/facets/lex/kind/artifact.md) (67), [capability](https://banes-lab.com/api/facets/lex/kind/capability.md) (331), [constraint](https://banes-lab.com/api/facets/lex/kind/constraint.md) (181), [mechanism](https://banes-lab.com/api/facets/lex/kind/mechanism.md) (39), [metric](https://banes-lab.com/api/facets/lex/kind/metric.md) (11), [model](https://banes-lab.com/api/facets/lex/kind/model.md) (17), [pattern](https://banes-lab.com/api/facets/lex/kind/pattern.md) (8), [principle](https://banes-lab.com/api/facets/lex/kind/principle.md) (6), [quality-attribute](https://banes-lab.com/api/facets/lex/kind/quality-attribute.md) (317), [style](https://banes-lab.com/api/facets/lex/kind/style.md) (2), [technique](https://banes-lab.com/api/facets/lex/kind/technique.md) (17)
- `category`: [architecture-review-evolution-governance](https://banes-lab.com/api/facets/lex/category/architecture-review-evolution-governance.md) (65), [behavioral-patterns](https://banes-lab.com/api/facets/lex/category/behavioral-patterns.md) (48), [causality-ordering-distributed-time](https://banes-lab.com/api/facets/lex/category/causality-ordering-distributed-time.md) (50), [codebase-system-architecture-styles](https://banes-lab.com/api/facets/lex/category/codebase-system-architecture-styles.md) (39), [contracts-interfaces-compatibility](https://banes-lab.com/api/facets/lex/category/contracts-interfaces-compatibility.md) (59), [control-coordination-centralization](https://banes-lab.com/api/facets/lex/category/control-coordination-centralization.md) (29), [core-modular-design](https://banes-lab.com/api/facets/lex/category/core-modular-design.md) (42), [core-vocabulary](https://banes-lab.com/api/facets/lex/category/core-vocabulary.md) (69), [correctness-determinism-verification](https://banes-lab.com/api/facets/lex/category/correctness-determinism-verification.md) (44), [creational-patterns](https://banes-lab.com/api/facets/lex/category/creational-patterns.md) (21), [domain-architecture](https://banes-lab.com/api/facets/lex/category/domain-architecture.md) (28), [error-handling-resilience](https://banes-lab.com/api/facets/lex/category/error-handling-resilience.md) (46), [event-messaging-async](https://banes-lab.com/api/facets/lex/category/event-messaging-async.md) (79), [metadata-self-description-declarative-systems](https://banes-lab.com/api/facets/lex/category/metadata-self-description-declarative-systems.md) (26), [metaprogramming-language-oriented-architecture](https://banes-lab.com/api/facets/lex/category/metaprogramming-language-oriented-architecture.md) (35), [model-architecture](https://banes-lab.com/api/facets/lex/category/model-architecture.md) (58), [observability-auditability-traceability](https://banes-lab.com/api/facets/lex/category/observability-auditability-traceability.md) (49), [plugin-extensibility-ioc](https://banes-lab.com/api/facets/lex/category/plugin-extensibility-ioc.md) (27), [portability-infrastructure-deployment](https://banes-lab.com/api/facets/lex/category/portability-infrastructure-deployment.md) (33), [quality-attributes](https://banes-lab.com/api/facets/lex/category/quality-attributes.md) (27), [runtime-discovery-dynamic-binding](https://banes-lab.com/api/facets/lex/category/runtime-discovery-dynamic-binding.md) (19), [scalability-performance-optimization](https://banes-lab.com/api/facets/lex/category/scalability-performance-optimization.md) (94), [schema-canonical-data-semantics](https://banes-lab.com/api/facets/lex/category/schema-canonical-data-semantics.md) (41), [security-privacy-compliance](https://banes-lab.com/api/facets/lex/category/security-privacy-compliance.md) (108), [self-healing-recovery-deployment-safety](https://banes-lab.com/api/facets/lex/category/self-healing-recovery-deployment-safety.md) (54), [solid-object-oriented-design](https://banes-lab.com/api/facets/lex/category/solid-object-oriented-design.md) (12), [streaming-pipeline-dataflow-processing](https://banes-lab.com/api/facets/lex/category/streaming-pipeline-dataflow-processing.md) (44), [structural-patterns](https://banes-lab.com/api/facets/lex/category/structural-patterns.md) (26), [taxonomy-classification-naming](https://banes-lab.com/api/facets/lex/category/taxonomy-classification-naming.md) (41), [transactions-state-concurrency](https://banes-lab.com/api/facets/lex/category/transactions-state-concurrency.md) (44)

## Entries

- [Ad-Hoc Design](https://banes-lab.com/records/lex/ad-hoc-design.md): Designing by improvisation with no deliberate structure or review, so the architecture accretes inconsistently.
- [Ad-Hoc Pattern Mixing](https://banes-lab.com/records/lex/ad-hoc-pattern-mixing.md): Combining unrelated design patterns arbitrarily with no coherent rationale, producing an inconsistent structure.
- [Analysis Overhead](https://banes-lab.com/records/lex/analysis-overhead.md): The degree to which analyzing the impact of every change before making it adds effort and slows delivery.
- [Architecture Criteria](https://banes-lab.com/records/lex/architecture-criteria.md): The requirement that explicit criteria define what a review judges an architecture against.
- [Architecture Drift](https://banes-lab.com/records/lex/architecture-drift.md): Gradual divergence of an implementation from its intended architecture as unreviewed changes accumulate.
- [Architecture Foundation](https://banes-lab.com/records/lex/architecture-foundation.md): The degree to which a system rests on a sound, deliberately designed architectural base rather than accreted structure.
- [Architecture Rules](https://banes-lab.com/records/lex/architecture-rules.md): The requirement that explicit, checkable rules govern how the architecture may be structured and evolved.
- [Assumption-Based Judgment](https://banes-lab.com/records/lex/assumption-based-judgment.md): Judging an architecture from untested assumptions instead of measured evidence, yielding unreliable conclusions.
- [Attribute Scenarios](https://banes-lab.com/records/lex/attribute-scenarios.md): A concrete scenario specifying how a quality attribute should hold under defined conditions and stimuli.
- [Automated Architecture Compliance](https://banes-lab.com/records/lex/automated-architecture-compliance.md): The ability to verify conformance to architectural rules automatically rather than by manual review.
- [Blind Change](https://banes-lab.com/records/lex/blind-change.md): Changing a system without analyzing what the change affects, so unintended consequences go unseen.
- [Cargo-Cult Pattern Use](https://banes-lab.com/records/lex/cargo-cult-pattern-use.md): Applying a design pattern by imitation without understanding the problem it solves, adding structure that fits nothing.
- [Change Safety](https://banes-lab.com/records/lex/change-safety.md): The degree to which a change can be made with confidence that its effects are understood and contained.
- [Clean Boundary Design](https://banes-lab.com/records/lex/clean-boundary-design.md): The ability to define clear component boundaries from the outset, free of legacy entanglement.
- [Competing Attributes](https://banes-lab.com/records/lex/competing-attributes.md): The degree to which improving one quality attribute forces a trade-off against another.
- [Consequences](https://banes-lab.com/records/lex/consequences.md): A recorded account of the trade-offs and downstream effects that follow from an architectural decision.
- [Continuous Improvement](https://banes-lab.com/records/lex/continuous-improvement.md): Iteratively refining a system's design in small, ongoing steps rather than in large infrequent overhauls.
- [Controlled Architecture Evolution](https://banes-lab.com/records/lex/controlled-architecture-evolution.md): The ability to let an architecture change over time within deliberate guardrails rather than drifting freely.
- [Criteria](https://banes-lab.com/records/lex/criteria.md): The requirement that explicit, agreed measures define how an assessment reaches its verdict.
- [Current State](https://banes-lab.com/records/lex/current-state.md): A conceptual representation of how a system is presently structured and behaves, used as the baseline for analysis.
- [Decision](https://banes-lab.com/records/lex/decision.md): A recorded architectural choice capturing what was chosen and the context in which it was made.
- [Decision History](https://banes-lab.com/records/lex/decision-history.md): The ability to trace why past architectural choices were made by consulting their recorded rationale.
- [Defect Detection](https://banes-lab.com/records/lex/defect-detection.md): The ability to find defects in a change before it is merged or shipped.
- [Design Criteria](https://banes-lab.com/records/lex/design-criteria.md): The requirement that explicit criteria define what a design review evaluates a proposal against.
- [Direct-to-main Unreviewed Change](https://banes-lab.com/records/lex/direct-to-main-unreviewed-change.md): Pushing changes straight to the main branch with no review, so unvetted code lands directly in production.
- [Documentation Maintenance](https://banes-lab.com/records/lex/documentation-maintenance.md): The degree to which keeping decision records current adds ongoing upkeep effort.
- [Early Defect Prevention](https://banes-lab.com/records/lex/early-defect-prevention.md): The ability to catch design flaws during review before they are built into the system.
- [Early Delivery with Guardrails](https://banes-lab.com/records/lex/early-delivery-with-guardrails.md): The ability to ship a minimal architecture quickly while keeping essential safeguards in place.
- [Easier Refactoring](https://banes-lab.com/records/lex/easier-refactoring.md): The ability to restructure code more safely because consistent patterns make change predictable.
- [Essential Quality Attributes](https://banes-lab.com/records/lex/essential-quality-attributes.md): The requirement that the few quality attributes critical to viability be satisfied before any others.
- [Fit-for-Purpose Architecture](https://banes-lab.com/records/lex/fit-for-purpose-architecture.md): The ability to shape an architecture to the problem it solves rather than to convention.
- [Future Scalability](https://banes-lab.com/records/lex/future-scalability.md): The degree to which a design can grow to meet higher future demand without rework.
- [Governance Discipline](https://banes-lab.com/records/lex/governance-discipline.md): The degree to which evolving an architecture continuously demands sustained governance to prevent uncontrolled drift.
- [Innovation/Autonomy](https://banes-lab.com/records/lex/innovation-autonomy.md): The degree to which enforcing standards constrains teams' freedom to innovate independently.
- [Legacy Constraints](https://banes-lab.com/records/lex/legacy-constraints.md): A binding limitation imposed by pre-existing legacy systems that a new design must accommodate.
- [Local Autonomy](https://banes-lab.com/records/lex/local-autonomy.md): The degree to which enforcing architectural consistency limits individual teams' freedom to make local choices.
- [Local Optimization](https://banes-lab.com/records/lex/local-optimization.md): The degree to which enforcing shared patterns sacrifices locally optimal one-off solutions.
- [Manual Architecture Review Only](https://banes-lab.com/records/lex/manual-architecture-review-only.md): Relying solely on human review to police architecture, with no automated checks, so violations slip through.
- [Measurable Architecture Rule](https://banes-lab.com/records/lex/measurable-architecture-rule.md): The requirement that an architectural rule be expressed as an objective, automatically checkable measure.
- [Naming/Structure Conventions](https://banes-lab.com/records/lex/naming-structure-conventions.md): A convention of naming and structuring code uniformly across a codebase so its shape is predictable.
- [Operability](https://banes-lab.com/records/lex/operability.md): The degree to which a system is easy to run, monitor, and keep healthy in production.
- [Over-Architecture](https://banes-lab.com/records/lex/over-architecture.md): Building more architectural structure than the problem needs, adding cost and rigidity with no payoff.
- [Predictable Evolution](https://banes-lab.com/records/lex/predictable-evolution.md): The ability to change a system with confidence that consistent structure keeps outcomes foreseeable.
- [Prioritized Refactoring](https://banes-lab.com/records/lex/prioritized-refactoring.md): The ability to rank refactoring work by assessed impact so effort targets the highest-value fixes.
- [Problem Decomposition](https://banes-lab.com/records/lex/problem-decomposition.md): Breaking a problem into fundamental sub-problems that can be reasoned about independently.
- [Quality](https://banes-lab.com/records/lex/quality.md): The degree to which a system meets its functional and non-functional expectations.
- [Quality Goals](https://banes-lab.com/records/lex/quality-goals.md): The requirement that target levels for key quality attributes be defined for an architecture to meet.
- [Regression Scope Selection](https://banes-lab.com/records/lex/regression-scope-selection.md): The ability to select exactly which tests a change requires by analyzing what it affects.
- [Remediation Planning](https://banes-lab.com/records/lex/remediation-planning.md): The ability to plan the steps that close the gap between a system's current and target states.
- [Reusable Architecture Guidance](https://banes-lab.com/records/lex/reusable-architecture-guidance.md): A body of proven architectural guidance packaged for reuse across projects.
- [Reuse of Established Patterns](https://banes-lab.com/records/lex/reuse-of-established-patterns.md): The degree to which designing from first principles forgoes the leverage of reusing proven patterns.
- [Review Standards](https://banes-lab.com/records/lex/review-standards.md): The requirement that agreed standards define what a code review checks for.
- [Risk Detection](https://banes-lab.com/records/lex/risk-detection.md): The ability to surface architectural risks early by reviewing structure before it is built.
- [Standard Patterns](https://banes-lab.com/records/lex/standard-patterns.md): A canonical, widely agreed reusable solution that a reference architecture prescribes for a recurring problem.
- [Standards Definition](https://banes-lab.com/records/lex/standards-definition.md): A defined, authoritative set of standards that units are expected to conform to.
- [Target State](https://banes-lab.com/records/lex/target-state.md): A conceptual representation of the desired future structure a system is being steered toward.
- [Trade-Off Analysis](https://banes-lab.com/records/lex/trade-off-analysis.md): The ability to weigh competing quality attributes and choose a balanced compromise between them.
- [Tribal Knowledge](https://banes-lab.com/records/lex/tribal-knowledge.md): Critical architectural knowledge held only in the developers' heads and never recorded, lost when they leave.
- [Uncoordinated Divergence](https://banes-lab.com/records/lex/uncoordinated-divergence.md): Teams independently diverging from a shared reference architecture, fragmenting the system into incompatible variants.
- [Unbounded Variation](https://banes-lab.com/records/lex/unbounded-variation.md): Allowing unlimited variation in how the same problem is solved, so the system sprawls into inconsistent one-offs.
- [Unknown Requirements](https://banes-lab.com/records/lex/unknown-requirements.md): The degree to which starting on a clean slate forces early decisions while requirements are still unknown.
- [Unreviewed Structural Change](https://banes-lab.com/records/lex/unreviewed-structural-change.md): Merging changes to architectural structure without review, letting unvetted design decisions into the system.
- [Incremental Change](https://banes-lab.com/records/lex/incremental-change.md): The requirement that a system evolve in small, reversible increments rather than large risky leaps.
- [Rule Maintenance](https://banes-lab.com/records/lex/rule-maintenance.md): The degree to which keeping fitness-function rules current adds ongoing upkeep effort.
- [Undefined Target](https://banes-lab.com/records/lex/undefined-target.md): Attempting to close a gap toward a goal that was never clearly defined, so progress cannot be judged.
- [Direct Callback Coupling](https://banes-lab.com/records/lex/direct-callback-coupling.md): Wiring a source to notify specific recipients by direct call, coupling it to each one.
- [Direct Method Invocation](https://banes-lab.com/records/lex/direct-method-invocation.md): Invoking an operation by direct method call, so it cannot be queued, logged, or undone.
- [Duplicated Workflow](https://banes-lab.com/records/lex/duplicated-workflow.md): Repeating the same overall algorithm in many places, each copy re-implementing the shared steps.
- [Exposed Internal Representation](https://banes-lab.com/records/lex/exposed-internal-representation.md): Forcing clients to traverse a collection through its internal structure, coupling them to that structure.
- [External State Reach-In](https://banes-lab.com/records/lex/external-state-reach-in.md): Reading or writing an object's internal state from outside to snapshot it, breaking its encapsulation.
- [Flat State Explosion](https://banes-lab.com/records/lex/flat-state-explosion.md): Enumerating every combination of conditions as a separate flat state, so the state count explodes.
- [Large Conditional Logic](https://banes-lab.com/records/lex/large-conditional-logic.md): Selecting behavior with a large branching conditional instead of pluggable strategy objects.
- [Mesh Dependencies](https://banes-lab.com/records/lex/mesh-dependencies.md): Letting every object refer directly to every other, forming a dense mesh of point-to-point dependencies.
- [Monolithic Handler](https://banes-lab.com/records/lex/monolithic-handler.md): Handling every case in one large handler instead of a chain of focused, single-purpose handlers.
- [Type-Switch Dispatch](https://banes-lab.com/records/lex/type-switch-dispatch.md): Dispatching behavior with a switch on an object's type instead of double dispatch through a visitor.
- [Centralized Interaction Logic](https://banes-lab.com/records/lex/centralized-interaction-logic.md): The ability to concentrate how a set of objects interact within one mediating component.
- [Controlled Variation](https://banes-lab.com/records/lex/controlled-variation.md): The ability to let subclasses vary only the designated steps of a fixed algorithm.
- [Decoupled Notification](https://banes-lab.com/records/lex/decoupled-notification.md): The ability to notify interested parties of a change without the source knowing who they are.
- [Deferred Execution](https://banes-lab.com/records/lex/deferred-execution.md): The ability to capture a request as an object so it can be run later, queued, or logged.
- [Exhaustive State Reasoning](https://banes-lab.com/records/lex/exhaustive-state-reasoning.md): The ability to enumerate and reason about every state a system can occupy and every transition between them.
- [Framework Reuse](https://banes-lab.com/records/lex/framework-reuse.md): The ability to reuse a fixed algorithm skeleton across many concrete implementations.
- [Guarded Transitions](https://banes-lab.com/records/lex/guarded-transitions.md): The ability to permit a state transition only when a specified condition holds.
- [Hierarchical States](https://banes-lab.com/records/lex/hierarchical-states.md): The ability to nest states so shared behavior is defined once on an enclosing state.
- [Lazy Traversal](https://banes-lab.com/records/lex/lazy-traversal.md): The ability to produce a collection's elements one at a time on demand rather than all at once.
- [Null-Check Elimination](https://banes-lab.com/records/lex/null-check-elimination.md): The ability to remove scattered null checks by substituting a benign do-nothing object.
- [Operation Extension Without Element Change](https://banes-lab.com/records/lex/operation-extension-without-element-change.md): The ability to add new operations over a structure without modifying its element classes.
- [Ordered Fallthrough](https://banes-lab.com/records/lex/ordered-fallthrough.md): The ability to offer a request to handlers in sequence until one of them accepts it.
- [Parallel Regions](https://banes-lab.com/records/lex/parallel-regions.md): The ability to model concurrently-active, independent regions of state within one machine.
- [Pluggable Handling](https://banes-lab.com/records/lex/pluggable-handling.md): The ability to add or reorder request handlers without changing the ones already in the chain.
- [Request Queuing](https://banes-lab.com/records/lex/request-queuing.md): The ability to hold requests captured as objects in a queue for later execution.
- [Runtime Behavior Selection](https://banes-lab.com/records/lex/runtime-behavior-selection.md): The ability to choose among interchangeable algorithms at runtime.
- [Snapshot/Restore](https://banes-lab.com/records/lex/snapshot-restore.md): The ability to capture an object's state and later restore it to that captured point.
- [State-Local Behavior](https://banes-lab.com/records/lex/state-local-behavior.md): The ability to attach behavior to each state so an object acts according to its current state.
- [Structure-Agnostic Iteration](https://banes-lab.com/records/lex/structure-agnostic-iteration.md): The ability to traverse a collection without depending on how it is internally organized.
- [Fail-Safe Defaults](https://banes-lab.com/records/lex/fail-safe-defaults.md): Defaulting to safe, benign behavior when a value or handler is absent rather than failing or branching.
- [Explicit State Model](https://banes-lab.com/records/lex/explicit-state-model.md): The requirement that an object's states and their transitions be modeled explicitly.
- [Explicit State Set](https://banes-lab.com/records/lex/explicit-state-set.md): The requirement that the complete set of possible states be defined up front.
- [Interchangeable Algorithms](https://banes-lab.com/records/lex/interchangeable-algorithms.md): The requirement that competing algorithms share one interface so they can be swapped freely.
- [Shared Behavioral Interface](https://banes-lab.com/records/lex/shared-behavioral-interface.md): The requirement that the real object and its null stand-in implement one common interface.
- [Stable Algorithm Skeleton](https://banes-lab.com/records/lex/stable-algorithm-skeleton.md): The requirement that the overall algorithm's structure stay fixed while specific steps vary.
- [Stable Element Hierarchy](https://banes-lab.com/records/lex/stable-element-hierarchy.md): The requirement that the set of element types stay fixed so new operations can be added over them.
- [Subject/Subscriber Contract](https://banes-lab.com/records/lex/subject-subscriber-contract.md): The requirement of an agreed interface by which subjects notify and subscribers receive updates.
- [Uniform Handler Interface](https://banes-lab.com/records/lex/uniform-handler-interface.md): The requirement that every handler in a chain share one interface so requests pass along uniformly.
- [Uniform Traversal Interface](https://banes-lab.com/records/lex/uniform-traversal-interface.md): The requirement that collections expose one common interface for stepping through their elements.
- [Class Count](https://banes-lab.com/records/lex/class-count.md): The degree to which extracting each algorithm into its own class raises the total number of classes.
- [Class Proliferation](https://banes-lab.com/records/lex/class-proliferation.md): The degree to which modeling each state as its own class multiplies the number of classes.
- [Coordination Complexity](https://banes-lab.com/records/lex/coordination-complexity.md): The degree of complexity in how objects must coordinate, which motivates a mediator.
- [Element Stability](https://banes-lab.com/records/lex/element-stability.md): The degree to which adding new operations stays easy only while the set of element types stays fixed.
- [Inheritance Coupling](https://banes-lab.com/records/lex/inheritance-coupling.md): The degree to which basing a template method on subclassing binds subclasses tightly to the base class.
- [Mediator God Object](https://banes-lab.com/records/lex/mediator-god-object.md): The degree to which concentrating interaction logic in a mediator risks growing it into an overloaded object.
- [Memory Footprint](https://banes-lab.com/records/lex/memory-footprint.md): The degree of memory consumed by retaining state snapshots for later restoration.
- [Silent No-Op Risk](https://banes-lab.com/records/lex/silent-no-op-risk.md): The degree to which a do-nothing stand-in can hide an error.
- [State Explosion](https://banes-lab.com/records/lex/state-explosion.md): The degree to which the number of explicit states grows unmanageably as conditions multiply.
- [Causation Tracking](https://banes-lab.com/records/lex/causation-tracking.md): Recording which event caused which, so cause-and-effect chains can be reconstructed later.
- [Correct Workflow Reasoning](https://banes-lab.com/records/lex/correct-workflow-reasoning.md): The ability to reason correctly about a workflow's steps by knowing their causal relationships.
- [Unordered Side Effects](https://banes-lab.com/records/lex/unordered-side-effects.md): Applying side effects in an order that ignores their causal dependencies, producing incorrect outcomes.
- [Arbitrary Reordering](https://banes-lab.com/records/lex/arbitrary-reordering.md): Reordering causally related operations freely, so effects can appear before their causes.
- [Causal Ordering](https://banes-lab.com/records/lex/causal-ordering.md): The requirement that operations be applied in an order consistent with their cause-and-effect relationships.
- [Eventual Consistency Safety](https://banes-lab.com/records/lex/eventual-consistency-safety.md): The degree to which replicas can converge over time without ever exposing a causally impossible state.
- [Latency/Availability](https://banes-lab.com/records/lex/latency-availability.md): The degree to which enforcing causal ordering across replicas costs added latency and reduced availability.
- [User-Visible Ordering Guarantees](https://banes-lab.com/records/lex/user-visible-ordering-guarantees.md): The ability to guarantee that users never observe an effect before its cause.
- [Causal Reasoning](https://banes-lab.com/records/lex/causal-reasoning.md): Reasoning about which events must precede others based on their causal relationships.
- [Ordering Semantics](https://banes-lab.com/records/lex/ordering-semantics.md): The requirement that a defined semantics specify when one event is considered to happen before another.
- [Parallel Execution](https://banes-lab.com/records/lex/parallel-execution.md): The degree to which enforcing a happens-before order constrains how much work can run in parallel.
- [Race Detection](https://banes-lab.com/records/lex/race-detection.md): The ability to detect data races by finding accesses with no happens-before ordering between them.
- [Correct Stateful Processing](https://banes-lab.com/records/lex/correct-stateful-processing.md): The ability to process a stream statefully with correct results by handling events in their proper order.
- [Ordering Key or Sequence](https://banes-lab.com/records/lex/ordering-key-or-sequence.md): The requirement that each event carry a key or sequence number that fixes its position in order.
- [Unordered Parallel Consumption](https://banes-lab.com/records/lex/unordered-parallel-consumption.md): Consuming an ordered event stream in parallel without preserving order, so state is updated out of sequence.
- [Dependency Declaration](https://banes-lab.com/records/lex/dependency-declaration.md): The requirement that each operation declare the operations it causally depends on.
- [Graph Complexity](https://banes-lab.com/records/lex/graph-complexity.md): The degree to which tracking fine-grained causal dependencies grows the dependency graph large and hard to reason about.
- [Hidden Dependency](https://banes-lab.com/records/lex/hidden-dependency.md): An unstated dependency between operations, so order-sensitive code breaks when the hidden ordering is not preserved.
- [Cycle Detection](https://banes-lab.com/records/lex/cycle-detection.md): The ability to detect cycles in a dependency graph before they cause deadlock or infinite resolution.
- [Dependency Extraction](https://banes-lab.com/records/lex/dependency-extraction.md): The requirement that dependencies between units be discovered and represented explicitly as a graph.
- [Dynamic Loading](https://banes-lab.com/records/lex/dynamic-loading.md): The degree to which resolving dependencies dynamically at runtime undermines a statically analyzable dependency graph.
- [Bidirectional Collaboration](https://banes-lab.com/records/lex/bidirectional-collaboration.md): The degree to which forbidding cycles prevents two components from depending on each other bidirectionally.
- [Build Order](https://banes-lab.com/records/lex/build-order.md): The ability to derive a correct build or execution order from a graph that contains no cycles.
- [Directed Dependencies](https://banes-lab.com/records/lex/directed-dependencies.md): The requirement that dependencies point in one direction only, forming no cycles.
- [Layering](https://banes-lab.com/records/lex/layering.md): A convention of organizing components into ordered layers where each may depend only on the layers beneath it.
- [Topological Ordering](https://banes-lab.com/records/lex/topological-ordering.md): The ability to linearize a directed acyclic graph into an order where every node follows its dependencies.
- [Concurrent Update Detection](https://banes-lab.com/records/lex/concurrent-update-detection.md): The ability to detect when two updates happened concurrently rather than one causally after the other.
- [Metadata Size](https://banes-lab.com/records/lex/metadata-size.md): The degree to which carrying a per-node counter for every node grows the ordering metadata with cluster size.
- [Node Identity](https://banes-lab.com/records/lex/node-identity.md): The requirement that each participating node have a distinct identity to index its own counter.
- [Single Global Clock Assumption](https://banes-lab.com/records/lex/single-global-clock-assumption.md): Assuming a single global clock orders all events, which fails across distributed nodes with independent clocks.
- [Version Vector](https://banes-lab.com/records/lex/version-vector.md): A set of per-node counters that together capture the causal history of a replicated item.
- [Happens-Before Reasoning](https://banes-lab.com/records/lex/happens-before-reasoning.md): Reasoning about event order using logical timestamps that respect the happens-before relation.
- [Logical Counter](https://banes-lab.com/records/lex/logical-counter.md): A monotonically increasing counter each process maintains to stamp events for logical ordering.
- [No Concurrent Causality Distinction](https://banes-lab.com/records/lex/no-concurrent-causality-distinction.md): The degree to which a single logical counter cannot tell concurrent events apart from causally ordered ones.
- [Partial Ordering](https://banes-lab.com/records/lex/partial-ordering.md): The ability to establish a consistent partial order over events without a shared physical clock.
- [Wall-Clock Ordering Assumption](https://banes-lab.com/records/lex/wall-clock-ordering-assumption.md): Ordering distributed events by wall-clock timestamps, which clock skew makes unreliable.
- [Clock Skew](https://banes-lab.com/records/lex/clock-skew.md): The degree to which physical clocks on different nodes drift apart, distorting time-based ordering.
- [Physical-Clock-Only Ordering](https://banes-lab.com/records/lex/physical-clock-only-ordering.md): Ordering events by physical clocks alone, which clock skew renders inconsistent across nodes.
- [Wall-Clock-Correlated Causal Order](https://banes-lab.com/records/lex/wall-clock-correlated-causal-order.md): The ability to order events causally while keeping timestamps close to wall-clock time.
- [Commutative Merge](https://banes-lab.com/records/lex/commutative-merge.md): The requirement that concurrent updates merge in any order to the same result.
- [Conflict-Free Replica Convergence](https://banes-lab.com/records/lex/conflict-free-replica-convergence.md): The ability for replicas to converge to one state automatically without conflict resolution.
- [Last-Write-Wins Overwrite](https://banes-lab.com/records/lex/last-write-wins-overwrite.md): Resolving concurrent updates by keeping the most recent write, rather than merging all updates.
- [Metadata Overhead](https://banes-lab.com/records/lex/metadata-overhead.md): The degree to which the bookkeeping a conflict-free type carries per value adds storage and transmission cost.
- [Identical Delivery Order Across Nodes](https://banes-lab.com/records/lex/identical-delivery-order-across-nodes.md): The ability to deliver messages to every node in the same total order.
- [Per-Node Independent Ordering](https://banes-lab.com/records/lex/per-node-independent-ordering.md): Letting each node decide message order independently, so replicas diverge on sequence.
- [Assumed Total Consistency And Availability](https://banes-lab.com/records/lex/assumed-total-consistency-and-availability.md): Assuming a distributed system can be fully consistent and available at once, ignoring partitions that force a choice.
- [Explicit Consistency/Availability Choice Under Partition](https://banes-lab.com/records/lex/explicit-consistency-availability-choice-under-partition.md): The ability to choose deliberately between consistency and availability when a network partition occurs.
- [Network Partition Possibility](https://banes-lab.com/records/lex/network-partition-possibility.md): The requirement that a distributed design account for the possibility of network partitions.
- [Consistency Assumed Free When Healthy](https://banes-lab.com/records/lex/consistency-assumed-free-when-healthy.md): Assuming consistency carries no cost while the network is healthy, ignoring the latency it still imposes.
- [Latency-Consistency Trade-off When Healthy](https://banes-lab.com/records/lex/latency-consistency-trade-off-when-healthy.md): The ability to weigh the latency-versus-consistency trade-off that remains even when the network is healthy.
- [Central Database Bottleneck](https://banes-lab.com/records/lex/central-database-bottleneck.md): Funneling all state through one shared database that becomes the system's scaling bottleneck.
- [Framework-Centric Core](https://banes-lab.com/records/lex/framework-centric-core.md): Building the core around a specific framework, so the framework's concerns permeate the domain.
- [Infrastructure-Centric Design](https://banes-lab.com/records/lex/infrastructure-centric-design.md): Designing the core around infrastructure details, so business logic depends on technical specifics.
- [Layer Leakage](https://banes-lab.com/records/lex/layer-leakage.md): Letting an inner layer depend on an outer one, violating the direction of the dependency rule.
- [Layer Skipping](https://banes-lab.com/records/lex/layer-skipping.md): Bypassing intermediate layers to call a distant layer directly, undermining the layering.
- [Monolithic Transform Function](https://banes-lab.com/records/lex/monolithic-transform-function.md): Doing all processing in one large transform instead of a series of composable filter stages.
- [Package by Technical Layer Only](https://banes-lab.com/records/lex/package-by-technical-layer-only.md): Organizing code by technical layer alone, scattering each feature across many packages.
- [Shared Monolithic Application](https://banes-lab.com/records/lex/shared-monolithic-application.md): Building one large shared application instead of composing independently-governed services.
- [Unbounded Big Ball of Mud](https://banes-lab.com/records/lex/unbounded-big-ball-of-mud.md): Letting a system grow without structure into a tangled mass with no clear boundaries.
- [Contract-Governed Service Reuse](https://banes-lab.com/records/lex/contract-governed-service-reuse.md): The ability to reuse services across an enterprise through well-defined contracts.
- [Database-Bottleneck Removal](https://banes-lab.com/records/lex/database-bottleneck-removal.md): The ability to eliminate the shared-database bottleneck by holding state in distributed memory.
- [Decentralized Ownership](https://banes-lab.com/records/lex/decentralized-ownership.md): The ability for separate teams to own, deploy and evolve their services independently.
- [External System Isolation](https://banes-lab.com/records/lex/external-system-isolation.md): The ability to isolate the core from external systems behind adapter boundaries.
- [Framework Independence](https://banes-lab.com/records/lex/framework-independence.md): The ability to keep business rules independent of any particular framework.
- [Independent Stage Testing](https://banes-lab.com/records/lex/independent-stage-testing.md): The ability to test each filter stage in isolation from the rest of the pipeline.
- [Infrastructure Independence](https://banes-lab.com/records/lex/infrastructure-independence.md): The ability to keep the core independent of the infrastructure it runs on.
- [Locality of Change](https://banes-lab.com/records/lex/locality-of-change.md): The ability to make a feature's changes in one place because its code is grouped together.
- [Reorderable Stages](https://banes-lab.com/records/lex/reorderable-stages.md): The ability to reorder or recombine independent processing stages.
- [Structured Code Organization](https://banes-lab.com/records/lex/structured-code-organization.md): The ability to organize code predictably by assigning each responsibility to a layer.
- [Transactional Simplicity](https://banes-lab.com/records/lex/transactional-simplicity.md): The ability to use straightforward local transactions when all state lives in one process.
- [Adapters](https://banes-lab.com/records/lex/adapters.md): Components that translate between a core's ports and the specific external technologies behind them.
- [Boundaries](https://banes-lab.com/records/lex/boundaries.md): The requirement that clear boundaries separate the concentric layers of the system.
- [Component Boundaries](https://banes-lab.com/records/lex/component-boundaries.md): The requirement that each component expose a well-defined boundary and interface.
- [Dependency Rule](https://banes-lab.com/records/lex/dependency-rule.md): The requirement that source-code dependencies point only inward, toward higher-level policy.
- [Domain Core](https://banes-lab.com/records/lex/domain-core.md): The requirement that pure domain logic occupy the core, isolated from external concerns.
- [Layer Separation](https://banes-lab.com/records/lex/layer-separation.md): The requirement that responsibilities be divided into distinct, ordered layers.
- [Ports](https://banes-lab.com/records/lex/ports.md): The requirement that the core define abstract interface points through which all external interaction passes.
- [Replicated In-Memory State](https://banes-lab.com/records/lex/replicated-in-memory-state.md): The requirement that application state be kept in replicated in-memory grids rather than a central store.
- [Unified Deployment Boundary](https://banes-lab.com/records/lex/unified-deployment-boundary.md): The requirement that the whole application build and deploy as one unit.
- [Uniform Stage Interface](https://banes-lab.com/records/lex/uniform-stage-interface.md): The requirement that every stage share one interface so stages can be composed freely.
- [Use Cases](https://banes-lab.com/records/lex/use-cases.md): The requirement that application operations be captured as explicit use cases in their own layer.
- [Anemic Layers](https://banes-lab.com/records/lex/anemic-layers.md): The degree to which strict layering produces thin pass-through layers that add indirection without logic.
- [End-to-End Traceability](https://banes-lab.com/records/lex/end-to-end-traceability.md): The degree to which decomposing flow into independent filters makes tracing a request end to end harder.
- [Feature Cohesion](https://banes-lab.com/records/lex/feature-cohesion.md): The degree to which all code serving one feature is grouped together rather than scattered by layer.
- [Independent Scaling](https://banes-lab.com/records/lex/independent-scaling.md): The degree to which a single deployable unit prevents scaling parts of the system independently.
- [Initial Complexity](https://banes-lab.com/records/lex/initial-complexity.md): The degree of upfront structural complexity introduced by defining ports and adapters.
- [Integration Overhead](https://banes-lab.com/records/lex/integration-overhead.md): The degree of effort required to wire independently-developed components together.
- [Operational Simplicity](https://banes-lab.com/records/lex/operational-simplicity.md): The degree to which a single deployable unit keeps building, deploying, and operating simple.
- [Shared Technical Concerns](https://banes-lab.com/records/lex/shared-technical-concerns.md): The degree to which grouping by feature complicates sharing cross-cutting technical code.
- [Ad-Hoc Endpoints](https://banes-lab.com/records/lex/ad-hoc-endpoints.md): Exposing inconsistent, one-off endpoints instead of a uniform interface, forcing clients to special-case each.
- [Ad-Hoc Payloads](https://banes-lab.com/records/lex/ad-hoc-payloads.md): Sending payloads with no agreed schema, so consumers must guess at structure and break on change.
- [Breaking API Change](https://banes-lab.com/records/lex/breaking-api-change.md): Changing an API in a way that violates its published contract, breaking existing clients.
- [Breaking Change](https://banes-lab.com/records/lex/breaking-change.md): A change that violates a component's contract, forcing consumers to update to keep working.
- [Breaking Changes](https://banes-lab.com/records/lex/breaking-changes.md): Changes that break existing consumers by altering behavior or shape they depend on.
- [External State Mutation](https://banes-lab.com/records/lex/external-state-mutation.md): Mutating state outside an object's own boundary, breaking the invariants it is supposed to guarantee.
- [Hidden Service Coupling](https://banes-lab.com/records/lex/hidden-service-coupling.md): An undeclared dependency between services that surfaces only at runtime, undermining independent evolution.
- [Implementation-First Integration](https://banes-lab.com/records/lex/implementation-first-integration.md): Integrating against a concrete implementation before agreeing a contract, coupling consumers to internals.
- [Implicit Assumptions](https://banes-lab.com/records/lex/implicit-assumptions.md): Relying on unstated preconditions a caller must satisfy, which break silently when they are violated.
- [Implicit Behavior](https://banes-lab.com/records/lex/implicit-behavior.md): Behavior a component performs that is not stated in its contract, surprising callers who come to depend on it.
- [Implicit Payloads](https://banes-lab.com/records/lex/implicit-payloads.md): Passing data whose shape and meaning are never declared, so consumers infer them and break on change.
- [Proprietary Coupling](https://banes-lab.com/records/lex/proprietary-coupling.md): Binding to a vendor's proprietary interface, forfeiting interoperability and portability.
- [Proprietary Drift](https://banes-lab.com/records/lex/proprietary-drift.md): Extending a standard protocol with proprietary features until it no longer interoperates with others.
- [Silent Breaking Changes](https://banes-lab.com/records/lex/silent-breaking-changes.md): Shipping a breaking change with no version bump or notice, so consumers fail without warning.
- [Strict Fragile Parsers](https://banes-lab.com/records/lex/strict-fragile-parsers.md): Parsers that reject any input deviating from an exact expectation, breaking on benign additions.
- [Undefined Results](https://banes-lab.com/records/lex/undefined-results.md): Returning results a contract never specifies for a given input, leaving callers with undefined behavior.
- [Compatibility Policy](https://banes-lab.com/records/lex/compatibility-policy.md): The declared rules governing which changes are compatible and how versions are managed.
- [Consistent Semantics](https://banes-lab.com/records/lex/consistent-semantics.md): The requirement that the same operation mean the same thing across every resource and endpoint.
- [Extensible Schema](https://banes-lab.com/records/lex/extensible-schema.md): A schema shaped so new fields can be added without breaking existing consumers.
- [Protocol Contract](https://banes-lab.com/records/lex/protocol-contract.md): The agreed rules of a protocol, such as its messages, formats and sequences, that both ends must honor.
- [Result Validation](https://banes-lab.com/records/lex/result-validation.md): The activity of checking that an operation's result satisfies its promised postconditions.
- [Semantic Contract](https://banes-lab.com/records/lex/semantic-contract.md): An agreement specifying not just the shape of an interface but the meaning and behavior it guarantees.
- [Unknown Field Handling](https://banes-lab.com/records/lex/unknown-field-handling.md): The requirement that a consumer ignore fields it does not recognize rather than fail on them.
- [API Usability](https://banes-lab.com/records/lex/api-usability.md): The degree to which an API is easy for developers to learn and use correctly.
- [Automated Validation](https://banes-lab.com/records/lex/automated-validation.md): The ability to check data automatically against a declared schema.
- [Client Compatibility](https://banes-lab.com/records/lex/client-compatibility.md): The degree to which existing clients continue to work as an API evolves.
- [Consumer-Driven Development](https://banes-lab.com/records/lex/consumer-driven-development.md): The ability to shape a provider's contract from the concrete needs of its consumers.
- [Consumer-Verified Compatibility](https://banes-lab.com/records/lex/consumer-verified-compatibility.md): The ability to verify a provider still satisfies the contracts its consumers depend on.
- [Contract Testing](https://banes-lab.com/records/lex/contract-testing.md): The activity of testing that an implementation honors the contract it declares.
- [Cross-System Communication](https://banes-lab.com/records/lex/cross-system-communication.md): The ability for independent systems to exchange and understand data with one another.
- [Incremental Deployment](https://banes-lab.com/records/lex/incremental-deployment.md): The ability to roll out changes gradually while old and new versions coexist.
- [Independent Consumers](https://banes-lab.com/records/lex/independent-consumers.md): The ability for consumers to evolve on their own schedule because the interface stays stable.
- [Multi-Client Integration](https://banes-lab.com/records/lex/multi-client-integration.md): The ability to serve many different clients through one compatible protocol.
- [Provider Change Safety](https://banes-lab.com/records/lex/provider-change-safety.md): The degree to which a provider can change without breaking its consumers, verified by their contracts.
- [Reliable Integration](https://banes-lab.com/records/lex/reliable-integration.md): The degree to which systems integrate correctly because their shared meaning is agreed, not just their shape.
- [Rolling Upgrades](https://banes-lab.com/records/lex/rolling-upgrades.md): The ability to upgrade instances one at a time while old and new versions interoperate.
- [Schema Evolution](https://banes-lab.com/records/lex/schema-evolution.md): The ability to change a data schema over time without breaking existing readers or writers.
- [Consumer Safety](https://banes-lab.com/records/lex/consumer-safety.md): The degree to which consumers are protected from breakage when a provider changes.
- [Data Quality](https://banes-lab.com/records/lex/data-quality.md): The degree to which data is accurate, complete, and fit for its intended use.
- [Integration](https://banes-lab.com/records/lex/integration.md): The degree to which separate systems are connected to operate as a unified whole.
- [Cleanup / Simplification](https://banes-lab.com/records/lex/cleanup-simplification.md): The activity of removing obsolete code and structure, which backward compatibility can hold back.
- [Cross-Domain Translation](https://banes-lab.com/records/lex/cross-domain-translation.md): The activity of mapping terms and structures between two domains that model the world differently.
- [Development Speed](https://banes-lab.com/records/lex/development-speed.md): The rate at which new functionality is built, which upfront contract rigor can slow.
- [Distributed Evolution](https://banes-lab.com/records/lex/distributed-evolution.md): The degree to which services can evolve independently, constrained by the contracts binding them.
- [Domain-Specific Optimization](https://banes-lab.com/records/lex/domain-specific-optimization.md): The degree to which a system is tuned for one domain, traded against broad interoperability.
- [Evolution](https://banes-lab.com/records/lex/evolution.md): The ability to change an interface over time, in tension with the stability its contract promises.
- [Evolution Speed](https://banes-lab.com/records/lex/evolution-speed.md): The rate at which an interface can change, which a commitment to stability deliberately limits.
- [Flexibility](https://banes-lab.com/records/lex/flexibility.md): The degree to which a component permits varied use, in tension with the invariants it must uphold.
- [Flexible Ingestion](https://banes-lab.com/records/lex/flexible-ingestion.md): The degree to which a system accepts loosely-structured input, in tension with a strict data contract.
- [Interface Overuse](https://banes-lab.com/records/lex/interface-overuse.md): The degree to which excessive interface abstraction adds indirection without proportional benefit.
- [Permissive APIs](https://banes-lab.com/records/lex/permissive-apis.md): The degree to which an API accepts loose or lenient input, in tension with strict preconditions.
- [Protocol Optimization](https://banes-lab.com/records/lex/protocol-optimization.md): The degree to which a protocol is tuned for performance, traded against broad compatibility.
- [Provider Autonomy](https://banes-lab.com/records/lex/provider-autonomy.md): The degree of freedom a provider retains to change, constrained by consumer-driven contracts.
- [Rapid Prototyping](https://banes-lab.com/records/lex/rapid-prototyping.md): The activity of building quick throwaway prototypes, which explicit contracts can slow.
- [Runtime Cost](https://banes-lab.com/records/lex/runtime-cost.md): The degree of runtime overhead incurred by checking conditions on every call.
- [Schema Flexibility](https://banes-lab.com/records/lex/schema-flexibility.md): The degree to which a schema tolerates variation, in tension with a strict contract.
- [Specialized Endpoints](https://banes-lab.com/records/lex/specialized-endpoints.md): The degree to which purpose-built endpoints are offered, traded against a uniform interface.
- [Strong Validation](https://banes-lab.com/records/lex/strong-validation.md): The degree to which input is strictly validated, in tension with tolerating unknown future fields.
- [Version Sprawl](https://banes-lab.com/records/lex/version-sprawl.md): The degree to which many concurrent versions accumulate and must be maintained.
- [Central Orchestrator Bottleneck](https://banes-lab.com/records/lex/central-orchestrator-bottleneck.md): Routing every interaction through one central orchestrator that becomes a bottleneck and single point of failure.
- [Centralized Control](https://banes-lab.com/records/lex/centralized-control.md): Concentrating decision-making authority in one place so nodes cannot act independently.
- [Fully Decentralized Control](https://banes-lab.com/records/lex/fully-decentralized-control.md): Leaving control fully decentralized with no central plane, so global runtime policy cannot be coordinated.
- [Independent Node Decisions](https://banes-lab.com/records/lex/independent-node-decisions.md): Letting each node decide independently with no agreement, so they diverge on shared state.
- [Local-Only Logs](https://banes-lab.com/records/lex/local-only-logs.md): Leaving logs scattered on each host with no aggregation, so cross-service analysis is impossible.
- [Pure Choreography](https://banes-lab.com/records/lex/pure-choreography.md): Coordinating a multi-step workflow purely through choreography when central orchestration is needed, scattering its logic.
- [Scattered Auth Implementations](https://banes-lab.com/records/lex/scattered-auth-implementations.md): Reimplementing authentication separately in each service instead of centralizing it.
- [Scattered Configuration](https://banes-lab.com/records/lex/scattered-configuration.md): Spreading configuration across many services with no single source, so values drift out of sync.
- [Split-Brain Coordination](https://banes-lab.com/records/lex/split-brain-coordination.md): Two nodes both believing they are leader and acting independently, corrupting shared state.
- [Agreed Single Value Across Nodes](https://banes-lab.com/records/lex/agreed-single-value-across-nodes.md): The ability for distributed nodes to agree on a single value despite failures.
- [Automatic Failover of Leadership](https://banes-lab.com/records/lex/automatic-failover-of-leadership.md): The ability to automatically elect a new leader when the current one fails.
- [Central-Orchestrator-Free Coordination](https://banes-lab.com/records/lex/central-orchestrator-free-coordination.md): The ability for services to coordinate through events without a central orchestrator.
- [Centralized Control of Distributed Runtime](https://banes-lab.com/records/lex/centralized-control-of-distributed-runtime.md): The ability to manage a distributed runtime's behavior from one central control point.
- [Cross-Service Analysis](https://banes-lab.com/records/lex/cross-service-analysis.md): The ability to analyze behavior across services by querying their aggregated logs.
- [Independent Ownership](https://banes-lab.com/records/lex/independent-ownership.md): The ability for each node or team to own and control its part without central approval.
- [Ordered Multi-Step Execution](https://banes-lab.com/records/lex/ordered-multi-step-execution.md): The ability to execute the steps of a workflow in a defined order.
- [Single-Writer Coordination](https://banes-lab.com/records/lex/single-writer-coordination.md): The ability to designate one elected node as the sole writer to coordinate updates.
- [Unified Config Management](https://banes-lab.com/records/lex/unified-config-management.md): The ability to manage all services' configuration from one place.
- [Unified Identity](https://banes-lab.com/records/lex/unified-identity.md): The ability to give users one identity recognized across all services.
- [Config Store](https://banes-lab.com/records/lex/config-store.md): A central store that holds configuration values for many services to read.
- [Coordinator](https://banes-lab.com/records/lex/coordinator.md): A component that directs the steps of a multi-service workflow in order.
- [Identity Provider](https://banes-lab.com/records/lex/identity-provider.md): A central service that authenticates identities and issues credentials for others to trust.
- [Log Aggregation](https://banes-lab.com/records/lex/log-aggregation.md): A facility that collects logs from many sources into one central store.
- [Management API](https://banes-lab.com/records/lex/management-api.md): A programmatic interface through which operators manage a distributed runtime's state.
- [Quorum](https://banes-lab.com/records/lex/quorum.md): The requirement that a majority of nodes agree before a decision commits.
- [Central Dependency Risk](https://banes-lab.com/records/lex/central-dependency-risk.md): The degree to which centralizing configuration makes the whole system depend on one config source.
- [Centralized Coordinator Coupling](https://banes-lab.com/records/lex/centralized-coordinator-coupling.md): The degree to which routing a workflow through a central coordinator couples participants to it.
- [Cost/Personal Data Exposure](https://banes-lab.com/records/lex/cost-personal-data-exposure.md): The degree to which aggregating all logs centrally raises storage cost and personal-data exposure.
- [Identity Provider Availability](https://banes-lab.com/records/lex/identity-provider-availability.md): The degree to which every login depends on the central identity provider staying available.
- [Anemic Encapsulation](https://banes-lab.com/records/lex/anemic-encapsulation.md): Wrapping data in a class that exposes it through trivial getters and setters, leaving its invariants unprotected.
- [Blob Class](https://banes-lab.com/records/lex/blob-class.md): A single class that absorbs many unrelated responsibilities, growing large and hard to change safely.
- [Centralized Runtime Control](https://banes-lab.com/records/lex/centralized-runtime-control.md): Concentrating runtime control in one place so otherwise-independent modules cannot act without it.
- [Context-Specific Coupling](https://banes-lab.com/records/lex/context-specific-coupling.md): Baking one caller's specific assumptions into a component, preventing its reuse elsewhere.
- [Copy-Paste Programming](https://banes-lab.com/records/lex/copy-paste-programming.md): Duplicating code by copying and pasting instead of extracting a shared abstraction.
- [Cross-Cutting Leakage](https://banes-lab.com/records/lex/cross-cutting-leakage.md): Letting a concern such as logging or security bleed into unrelated modules throughout the code.
- [Deep Inheritance Hierarchy](https://banes-lab.com/records/lex/deep-inheritance-hierarchy.md): Stacking many layers of subclassing, so behavior is scattered and fragile to change.
- [Exposed Internals](https://banes-lab.com/records/lex/exposed-internals.md): Making a module's internal fields and workings public, so callers depend on details that should be hidden.
- [Implementation-Specific Contracts](https://banes-lab.com/records/lex/implementation-specific-contracts.md): Defining an interface around one implementation's quirks, so no alternative can satisfy it.
- [Leaky Abstraction](https://banes-lab.com/records/lex/leaky-abstraction.md): An abstraction that forces callers to understand its underlying implementation to use it correctly.
- [Mixed Layers](https://banes-lab.com/records/lex/mixed-layers.md): Interleaving different architectural layers' logic in one place instead of keeping each concern separate.
- [Monolithic Procedures](https://banes-lab.com/records/lex/monolithic-procedures.md): Writing large all-in-one procedures that cannot be recombined from smaller, independent parts.
- [Shared Runtime Dependency](https://banes-lab.com/records/lex/shared-runtime-dependency.md): Coupling supposedly-independent modules through a shared runtime component they all depend on.
- [Tight Coupling](https://banes-lab.com/records/lex/tight-coupling.md): Binding components so closely that a change in one forces changes in the others.
- [Bounded Context Ownership](https://banes-lab.com/records/lex/bounded-context-ownership.md): The ability for a team or module to own and control one bounded part of the system.
- [Change Isolation](https://banes-lab.com/records/lex/change-isolation.md): The ability to confine the impact of a change behind a boundary so callers are unaffected.
- [Independent Testing](https://banes-lab.com/records/lex/independent-testing.md): The ability to test a component in isolation without standing up its collaborators.
- [Internal Refactoring](https://banes-lab.com/records/lex/internal-refactoring.md): The ability to rework a module's internals freely as long as its interface stays stable.
- [Invariant Protection](https://banes-lab.com/records/lex/invariant-protection.md): The ability to guarantee an object's rules always hold by controlling all access to its state.
- [Product Lines](https://banes-lab.com/records/lex/product-lines.md): The ability to build a family of related products from shared, reusable components.
- [Shared Libraries](https://banes-lab.com/records/lex/shared-libraries.md): The ability to factor common functionality into libraries reused across projects.
- [Strategy Swap](https://banes-lab.com/records/lex/strategy-swap.md): The ability to replace one interchangeable algorithm or implementation with another.
- [Test Isolation](https://banes-lab.com/records/lex/test-isolation.md): The ability to exercise a unit under test without its dependencies interfering.
- [Vendor Swap](https://banes-lab.com/records/lex/vendor-swap.md): The ability to replace one vendor's implementation with another behind a stable interface.
- [Delegation](https://banes-lab.com/records/lex/delegation.md): Forwarding work to a contained collaborator object rather than inheriting the behavior.
- [Deep Optimization](https://banes-lab.com/records/lex/deep-optimization.md): The practice of optimizing heavily against a specific implementation's traits, which ties code to it.
- [YAGNI](https://banes-lab.com/records/lex/yagni.md): You Aren't Gonna Need It: build only what current requirements demand and defer speculative generality.
- [Canonical Source](https://banes-lab.com/records/lex/canonical-source.md): The requirement that each piece of knowledge have one authoritative definition rather than copies.
- [Contract Compatibility](https://banes-lab.com/records/lex/contract-compatibility.md): The requirement that alternative implementations honor the same interface contract.
- [Explicit Interfaces](https://banes-lab.com/records/lex/explicit-interfaces.md): The requirement that a module interact only through declared interfaces, not its hidden internals.
- [Interface Conformance](https://banes-lab.com/records/lex/interface-conformance.md): The requirement that each implementation fully conform to the shared interface's contract.
- [Interface Definition](https://banes-lab.com/records/lex/interface-definition.md): The requirement that an abstraction expose a defined interface separate from its implementation.
- [Stable Semantics](https://banes-lab.com/records/lex/stable-semantics.md): The requirement that an abstraction's meaning stay consistent even as its implementations change.
- [Coordination Cost](https://banes-lab.com/records/lex/coordination-cost.md): The degree of extra coordination required when components are made fully independent.
- [Excessive Fragmentation](https://banes-lab.com/records/lex/excessive-fragmentation.md): The degree to which splitting responsibilities too finely scatters logic across many small units.
- [Locality of Behavior](https://banes-lab.com/records/lex/locality-of-behavior.md): The degree to which keeping related behavior together can conflict with removing all duplication.
- [Over-Generalization](https://banes-lab.com/records/lex/over-generalization.md): The degree to which making code reusable for every case adds abstraction that harms clarity.
- [Over-Layering](https://banes-lab.com/records/lex/over-layering.md): The degree to which adding separating layers introduces indirection that outweighs the separation gained.
- [Over-Specialization](https://banes-lab.com/records/lex/over-specialization.md): The degree to which pursuing tight cohesion can narrow a unit's purpose too far to reuse.
- [Performance Overhead](https://banes-lab.com/records/lex/performance-overhead.md): The degree of runtime cost added by composing behavior from many small, indirected parts.
- [Simplicity for Trivial Reuse](https://banes-lab.com/records/lex/simplicity-for-trivial-reuse.md): The degree to which composition adds wiring that inheritance would make simpler for trivial reuse.
- [Specialized Optimization](https://banes-lab.com/records/lex/specialized-optimization.md): The degree to which optimizing for one implementation undermines the ability to swap implementations.
- [Metrics](https://banes-lab.com/records/lex/metrics.md): Quantitative measurements a system emits about its state and behavior for monitoring and analysis.
- [Contracts](https://banes-lab.com/records/lex/contracts.md): Explicit, enforceable agreements specifying the inputs, outputs, and guarantees between components.
- [Independent Deployment](https://banes-lab.com/records/lex/independent-deployment.md): The ability to release a component to production without coordinating the deployment of others.
- [Delivery Speed](https://banes-lab.com/records/lex/delivery-speed.md): The rate at which changes are delivered to production.
- [Boilerplate](https://banes-lab.com/records/lex/boilerplate.md): Repetitive, mandatory scaffolding code that adds ceremony without domain value.
- [Schema](https://banes-lab.com/records/lex/schema.md): A formal definition of the structure, types, and constraints of data.
- [Compatibility](https://banes-lab.com/records/lex/compatibility.md): The degree to which a component interoperates with other versions or systems without modification.
- [Cost](https://banes-lab.com/records/lex/cost.md): The resource or financial expenditure required to build, run, or change a system.
- [Self-Healing](https://banes-lab.com/records/lex/self-healing.md): The ability of a system to detect and recover from failures without human intervention.
- [Metadata](https://banes-lab.com/records/lex/metadata.md): Descriptive data about a system's structure, capabilities, or content, consumed to drive behavior.
- [Discovery](https://banes-lab.com/records/lex/discovery.md): The ability to locate available components, services, or capabilities at runtime.
- [Iteration Speed](https://banes-lab.com/records/lex/iteration-speed.md): The rate at which cycles of change and feedback can be completed.
- [Race Conditions](https://banes-lab.com/records/lex/race-conditions.md): A defect where the outcome depends on the uncontrolled interleaving of concurrent operations.
- [Ports and Adapters](https://banes-lab.com/records/lex/ports-and-adapters.md): An architecture isolating core logic behind ports, with adapters binding it to external technologies.
- [Operational Complexity](https://banes-lab.com/records/lex/operational-complexity.md): The effort and intricacy required to deploy, run, and maintain a system in production.
- [Standards](https://banes-lab.com/records/lex/standards.md): Agreed conventions and specifications that components conform to for interoperability and consistency.
- [Single Point of Failure](https://banes-lab.com/records/lex/single-point-of-failure.md): A component whose failure alone halts the entire system because it has no redundancy.
- [Debugging](https://banes-lab.com/records/lex/debugging.md): The activity of locating and diagnosing the cause of a defect.
- [Specification](https://banes-lab.com/records/lex/specification.md): A precise, authoritative description of required behavior, structure, or interface.
- [False Positives](https://banes-lab.com/records/lex/false-positives.md): Incorrect positive results reported when the detected condition is not present.
- [Ownership](https://banes-lab.com/records/lex/ownership.md): A clear assignment of responsibility for a component to a person or team.
- [Silent Failure](https://banes-lab.com/records/lex/silent-failure.md): A failure that occurs without surfacing any error, log, or signal, leaving it undetected.
- [Message Contract](https://banes-lab.com/records/lex/message-contract.md): The agreed schema and semantics of messages exchanged between components.
- [Replay](https://banes-lab.com/records/lex/replay.md): The ability to re-process a recorded sequence of events to reconstruct or recover state.
- [DSLs](https://banes-lab.com/records/lex/dsls.md): Domain-specific languages, small notations tailored to express solutions within one problem domain.
- [Acceptance Criteria](https://banes-lab.com/records/lex/acceptance-criteria.md): Predefined conditions a deliverable must satisfy to be accepted as complete and correct.
- [Ambiguous Naming](https://banes-lab.com/records/lex/ambiguous-naming.md): Identifiers whose meaning is unclear or open to multiple interpretations, obscuring intent.
- [Automated Enforcement](https://banes-lab.com/records/lex/automated-enforcement.md): Machine-applied checking that rules and policies hold, catching violations without manual review.
- [Automation](https://banes-lab.com/records/lex/automation.md): The execution of tasks by software or machinery without manual intervention.
- [Boolean Flag Soup](https://banes-lab.com/records/lex/boolean-flag-soup.md): Representing state through many interdependent boolean flags, producing tangled and invalid combinations.
- [Capacity Planning](https://banes-lab.com/records/lex/capacity-planning.md): Forecasting resource demand and provisioning capacity to meet it without waste or shortfall.
- [Code Generation](https://banes-lab.com/records/lex/code-generation.md): Producing source code automatically from a higher-level model, schema, or specification.
- [Composition Root](https://banes-lab.com/records/lex/composition-root.md): The single startup location where an application's object graph is assembled and its dependencies wired.
- [Context](https://banes-lab.com/records/lex/context.md): The surrounding information and circumstances captured to make a decision, event, or log entry interpretable.
- [Continuous Processing](https://banes-lab.com/records/lex/continuous-processing.md): Handling data incrementally as it arrives, rather than in discrete scheduled batches.
- [Controlled Access](https://banes-lab.com/records/lex/controlled-access.md): Mediated, restricted access to a resource so that only permitted operations reach it.
- [Controlled Evolution](https://banes-lab.com/records/lex/controlled-evolution.md): The managed, deliberate change of a system over time without breaking existing consumers.
- [Controlled Inputs](https://banes-lab.com/records/lex/controlled-inputs.md): Inputs that are fixed, bounded, or fully specified so that a computation's behavior is reproducible.
- [Cross-Cutting Concerns](https://banes-lab.com/records/lex/cross-cutting-concerns.md): Concerns such as logging, security, or transactions whose implementation spans many modules rather than localizing to one.
- [Cyclic Dependencies](https://banes-lab.com/records/lex/cyclic-dependencies.md): Dependencies that form a cycle among components, preventing independent build, test, or reasoning.
- [Damage Limitation](https://banes-lab.com/records/lex/damage-limitation.md): Containing the blast radius of a failure or breach so its impact stays bounded.
- [Evaluation](https://banes-lab.com/records/lex/evaluation.md): The systematic assessment of a model or system's behavior and quality against defined criteria.
- [Evidence](https://banes-lab.com/records/lex/evidence.md): Recorded proof that substantiates a claim, decision, or compliance requirement.
- [Explicit Inputs](https://banes-lab.com/records/lex/explicit-inputs.md): All data a computation needs supplied through its parameters rather than read from ambient or hidden state.
- [Fallback](https://banes-lab.com/records/lex/fallback.md): An alternative path or default invoked automatically when the primary operation fails or is unavailable.
- [Hidden Dependencies](https://banes-lab.com/records/lex/hidden-dependencies.md): Dependencies a component relies on but does not declare in its interface, surfacing only at runtime.
- [Hidden Side Effects](https://banes-lab.com/records/lex/hidden-side-effects.md): State changes a function performs that are not evident from its name or signature, surprising callers.
- [Independent Work Units](https://banes-lab.com/records/lex/independent-work-units.md): Work partitioned into discrete units that execute in isolation, without shared mutable state or ordering dependencies.
- [Large Input Handling](https://banes-lab.com/records/lex/large-input-handling.md): The ability to process inputs too large to fit in memory, through streaming or chunking.
- [Legal-Transition Enforcement](https://banes-lab.com/records/lex/legal-transition-enforcement.md): Rejecting any state change that is not a permitted transition.
- [Plugin Swap](https://banes-lab.com/records/lex/plugin-swap.md): Replacing one plugin implementation with another at a defined seam without modifying the host.
- [Plugins](https://banes-lab.com/records/lex/plugins.md): Independently-developed components that attach to a host at defined extension points to add capabilities.
- [Policy](https://banes-lab.com/records/lex/policy.md): A declared set of rules governing what actions are permitted or denied within a system.
- [Pub/Sub](https://banes-lab.com/records/lex/pub-sub.md): A messaging pattern in which publishers emit messages to topics and subscribers receive them without direct coupling.
- [Recovery](https://banes-lab.com/records/lex/recovery.md): Restoring a system to correct operation or a consistent state after a failure.
- [Reuse](https://banes-lab.com/records/lex/reuse.md): Using an existing component, module, or solution in a new context rather than rebuilding it.
- [Runtime Indirection](https://banes-lab.com/records/lex/runtime-indirection.md): Resolving a binding or call target at runtime through an intermediary layer rather than a direct, static reference.
- [Safe Defaults](https://banes-lab.com/records/lex/safe-defaults.md): Choosing default configurations and behaviors that are safe when left unchanged.
- [Safe Refactoring](https://banes-lab.com/records/lex/safe-refactoring.md): Changing a system's internal structure with confidence that its observable behavior is preserved.
- [Safe Substitution](https://banes-lab.com/records/lex/safe-substitution.md): Replacing a component or expression with an equivalent one without altering program correctness.
- [Saga](https://banes-lab.com/records/lex/saga.md): A pattern that manages a distributed transaction as a sequence of local transactions, each with a compensating action for rollback.
- [Secure Defaults](https://banes-lab.com/records/lex/secure-defaults.md): Making the default configuration the most secure option, requiring explicit action to reduce security.
- [Model Drift](https://banes-lab.com/records/lex/model-drift.md): The gradual loss of a model's fidelity to the reality it represents, as data or conditions change over time.
- [Stable Contracts](https://banes-lab.com/records/lex/stable-contracts.md): Interfaces and agreements that remain unchanged over time so that consumers can depend on them safely.
- [Thresholds](https://banes-lab.com/records/lex/thresholds.md): Configured boundary values that trigger an alert or action when a measured metric crosses them.
- [Time Budget](https://banes-lab.com/records/lex/time-budget.md): A bounded maximum amount of time allotted for an operation to complete.
- [Time Cost](https://banes-lab.com/records/lex/time-cost.md): The amount of time an activity requires, weighed as a cost against its benefit.
- [Type Metadata](https://banes-lab.com/records/lex/type-metadata.md): Descriptive data about the types of a structure's fields, available for inspection at runtime.
- [Undo/Redo](https://banes-lab.com/records/lex/undo-redo.md): The ability to reverse a previously applied operation and to reapply it.
- [Assumption-Driven Delivery](https://banes-lab.com/records/lex/assumption-driven-delivery.md): Shipping on untested assumptions about behavior instead of validating that requirements are met.
- [Environment-Sensitive Behavior](https://banes-lab.com/records/lex/environment-sensitive-behavior.md): Behavior that changes with the host environment, so the same run yields different results elsewhere.
- [Example-Only Testing](https://banes-lab.com/records/lex/example-only-testing.md): Testing only a few hand-picked examples instead of properties that must hold across all inputs.
- [Floating Dependencies](https://banes-lab.com/records/lex/floating-dependencies.md): Depending on unpinned, floating dependency versions, so builds are not reproducible.
- [Hidden Behavior](https://banes-lab.com/records/lex/hidden-behavior.md): Behavior triggered by hidden state or side effects, so outcomes surprise callers.
- [Hidden IO](https://banes-lab.com/records/lex/hidden-io.md): Performing input/output inside a supposedly pure function, hiding side effects from callers.
- [Hidden Time/Randomness/Global State](https://banes-lab.com/records/lex/hidden-time-randomness-global-state.md): Reading the clock, randomness, or global state inside a computation, making its output nondeterministic.
- [Implementation-Only Testing](https://banes-lab.com/records/lex/implementation-only-testing.md): Testing only against the current implementation's behavior rather than the specified contract.
- [Informal Validation Only](https://banes-lab.com/records/lex/informal-validation-only.md): Relying only on informal checks and testing where a formal proof of correctness is warranted.
- [Side Effects](https://banes-lab.com/records/lex/side-effects.md): Producing observable side effects in an expression, so it cannot be replaced by its value.
- [Unchecked Dynamic Code](https://banes-lab.com/records/lex/unchecked-dynamic-code.md): Running dynamically generated or evaluated code that static analysis cannot inspect for defects.
- [Undefined Behavior](https://banes-lab.com/records/lex/undefined-behavior.md): Relying on operations whose result is unspecified, so outcomes vary unpredictably across runs or platforms.
- [Untested Implementation](https://banes-lab.com/records/lex/untested-implementation.md): Shipping code with no tests, so its conformance to the specification is unverified.
- [Behavior Validation](https://banes-lab.com/records/lex/behavior-validation.md): The ability to confirm a system behaves as its specification requires.
- [Broad Input Exploration](https://banes-lab.com/records/lex/broad-input-exploration.md): The ability to exercise a function across a wide, generated range of inputs.
- [Mathematical Assurance](https://banes-lab.com/records/lex/mathematical-assurance.md): The ability to prove mathematically that a system meets its specification.
- [Regression Safety](https://banes-lab.com/records/lex/regression-safety.md): The ability to catch regressions when code changes by re-running tests.
- [Reliable Automation](https://banes-lab.com/records/lex/reliable-automation.md): The ability to automate a process reliably because it repeats identically each run.
- [Reliable Testing](https://banes-lab.com/records/lex/reliable-testing.md): The ability to test dependably because the same inputs always produce the same outputs.
- [Safe Operation](https://banes-lab.com/records/lex/safe-operation.md): The ability to operate without producing incorrect or harmful results.
- [Safe Sharing](https://banes-lab.com/records/lex/safe-sharing.md): The ability to share data freely across threads because it cannot be modified.
- [Specification Compliance](https://banes-lab.com/records/lex/specification-compliance.md): The ability to confirm an implementation conforms to its specification.
- [Formal Specification](https://banes-lab.com/records/lex/formal-specification.md): A precise, mathematical statement of what a system must do, against which it is proven.
- [Ruleset](https://banes-lab.com/records/lex/ruleset.md): The set of rules a static analyzer checks source code against.
- [Tests](https://banes-lab.com/records/lex/tests.md): Executable checks that assert a system behaves as intended.
- [Controlled State](https://banes-lab.com/records/lex/controlled-state.md): The requirement that all inputs and state affecting a computation be controlled and known.
- [Deterministic Behavior](https://banes-lab.com/records/lex/deterministic-behavior.md): The requirement that the code under test produce the same result for the same inputs.
- [No Side Effects](https://banes-lab.com/records/lex/no-side-effects.md): The requirement that a function compute its result without observable side effects.
- [Properties/Invariants](https://banes-lab.com/records/lex/properties-invariants.md): The requirement that the general properties or invariants a function must satisfy be defined.
- [Value Semantics](https://banes-lab.com/records/lex/value-semantics.md): The requirement that values be compared and copied by content rather than by reference identity.
- [Versioned Inputs](https://banes-lab.com/records/lex/versioned-inputs.md): The requirement that all inputs to a build or computation be pinned to specific versions.
- [Allocation Cost](https://banes-lab.com/records/lex/allocation-cost.md): The degree of extra memory allocation incurred by creating new immutable values instead of mutating in place.
- [Continuous Updates](https://banes-lab.com/records/lex/continuous-updates.md): The degree to which pinning everything for reproducibility conflicts with continuously updating dependencies.
- [Cost/Complexity](https://banes-lab.com/records/lex/cost-complexity.md): The degree of cost and complexity added by formally proving a system correct.
- [Dynamic Runtime Behavior](https://banes-lab.com/records/lex/dynamic-runtime-behavior.md): The degree to which runtime-adaptive behavior undermines a system's predictability.
- [Encapsulation Extremes](https://banes-lab.com/records/lex/encapsulation-extremes.md): The degree to which hiding internals too strictly makes a unit's behavior hard to observe in tests.
- [Fitness for Use](https://banes-lab.com/records/lex/fitness-for-use.md): The degree to which a product meets the needs of its users.
- [Real-World Variability](https://banes-lab.com/records/lex/real-world-variability.md): The degree to which controlling conditions for repeatability diverges from real-world variability.
- [Runtime Adaptivity](https://banes-lab.com/records/lex/runtime-adaptivity.md): The degree to which making behavior deterministic limits adapting dynamically at runtime.
- [Shrinking/Debug Complexity](https://banes-lab.com/records/lex/shrinking-debug-complexity.md): The degree to which reducing a failing generated case to a minimal example adds debugging complexity.
- [Spec Maintenance](https://banes-lab.com/records/lex/spec-maintenance.md): The degree of ongoing effort to keep a specification current as the system evolves.
- [Stateful IO](https://banes-lab.com/records/lex/stateful-io.md): The degree to which stateful input/output conflicts with expressions being replaceable by their values.
- [Stateful Operations](https://banes-lab.com/records/lex/stateful-operations.md): The degree to which operations that depend on or mutate state conflict with purity.
- [Thread Safety](https://banes-lab.com/records/lex/thread-safety.md): The degree to which data can be accessed concurrently without corruption.
- [Complex Factory Hierarchies](https://banes-lab.com/records/lex/complex-factory-hierarchies.md): Building elaborate parallel factory class hierarchies where cloning an existing configured instance would suffice.
- [Concrete Constructor Coupling](https://banes-lab.com/records/lex/concrete-constructor-coupling.md): Instantiating concrete classes directly with constructors, coupling callers to specific implementations.
- [Global Mutable State](https://banes-lab.com/records/lex/global-mutable-state.md): Exposing global variables that any code can mutate, creating hidden coupling and nondeterminism.
- [Mixed Product Families](https://banes-lab.com/records/lex/mixed-product-families.md): Combining products from different incompatible families, producing inconsistent sets of objects.
- [Scattered Construction Logic](https://banes-lab.com/records/lex/scattered-construction-logic.md): Spreading object-creation logic across many call sites instead of centralizing it in a factory.
- [Telescoping Constructor](https://banes-lab.com/records/lex/telescoping-constructor.md): Overloading constructors with ever more parameters to cover optional fields, producing unreadable call sites.
- [Controlled Instantiation](https://banes-lab.com/records/lex/controlled-instantiation.md): The ability to govern how and when an object is created.
- [Deferred Instantiation](https://banes-lab.com/records/lex/deferred-instantiation.md): The ability to let subclasses decide which class to instantiate, deferring the choice from the base class.
- [Dynamic Object Creation](https://banes-lab.com/records/lex/dynamic-object-creation.md): The ability to create new objects at runtime by cloning existing configured instances.
- [Family-Level Replacement](https://banes-lab.com/records/lex/family-level-replacement.md): The ability to swap an entire family of related products by changing a single factory.
- [Polymorphic Construction](https://banes-lab.com/records/lex/polymorphic-construction.md): The ability to create objects through a common interface without naming their concrete classes.
- [Shared Resource Access](https://banes-lab.com/records/lex/shared-resource-access.md): The ability to give many callers coordinated access to one shared resource.
- [Valid Object Creation](https://banes-lab.com/records/lex/valid-object-creation.md): The ability to construct an object only once all its required parts are supplied and validated.
- [Cloneable Template Object](https://banes-lab.com/records/lex/cloneable-template-object.md): The requirement that a prototype object support being copied to produce new instances.
- [Creation Variation](https://banes-lab.com/records/lex/creation-variation.md): A precondition that different variants of a product must be produced depending on runtime context.
- [Related Product Variants](https://banes-lab.com/records/lex/related-product-variants.md): The requirement that products form families of related variants meant to be used together.
- [Single-Instance Need](https://banes-lab.com/records/lex/single-instance-need.md): A precondition that exactly one instance of a type must exist across the system.
- [Subclass-Controlled Creation](https://banes-lab.com/records/lex/subclass-controlled-creation.md): The requirement that subclasses determine which concrete product a creator instantiates.
- [Complex Construction](https://banes-lab.com/records/lex/complex-construction.md): The degree of complexity in assembling an object that motivates a step-by-step builder.
- [Copy Semantics](https://banes-lab.com/records/lex/copy-semantics.md): The degree of care required to define correct deep versus shallow copying when cloning objects.
- [Inheritance Complexity](https://banes-lab.com/records/lex/inheritance-complexity.md): The degree to which relying on subclassing to vary creation adds to the inheritance hierarchy's complexity.
- [Anemic Model](https://banes-lab.com/records/lex/anemic-model.md): A domain model holding only data with no behavior, pushing all logic into separate procedures.
- [Anemic Transaction Script](https://banes-lab.com/records/lex/anemic-transaction-script.md): Implementing business logic as procedural scripts over data-only objects, with no rich domain model.
- [Implicit Integration](https://banes-lab.com/records/lex/implicit-integration.md): Integrating contexts through undocumented, assumed connections instead of explicit, mapped relationships.
- [Shared Global Model](https://banes-lab.com/records/lex/shared-global-model.md): Forcing one global model across the whole system, so unrelated parts are coupled through it.
- [Shared Model Coupling](https://banes-lab.com/records/lex/shared-model-coupling.md): Coupling a domain to an external system's model by sharing it directly, so their changes ripple across.
- [Business Rule Encapsulation](https://banes-lab.com/records/lex/business-rule-encapsulation.md): The ability to keep business rules inside the domain objects they govern.
- [Cross-Entity Domain Logic](https://banes-lab.com/records/lex/cross-entity-domain-logic.md): The ability to place logic that spans several entities in a dedicated domain service.
- [Domain Alignment](https://banes-lab.com/records/lex/domain-alignment.md): The ability to keep the software model closely aligned with the business domain it serves.
- [Identity-Based Equality](https://banes-lab.com/records/lex/identity-based-equality.md): The ability to treat two objects as the same when they share an identity, regardless of their attributes.
- [Legacy/System Integration](https://banes-lab.com/records/lex/legacy-system-integration.md): The ability to integrate a legacy or external system without letting its model corrupt the domain.
- [Lifecycle Tracking](https://banes-lab.com/records/lex/lifecycle-tracking.md): The ability to track an entity as the same thing through changes over its lifetime.
- [Root-Guarded Invariants](https://banes-lab.com/records/lex/root-guarded-invariants.md): The ability to enforce an aggregate's invariants by routing all changes through its root.
- [Self-Validating Values](https://banes-lab.com/records/lex/self-validating-values.md): The ability for a value object to guarantee its own validity at construction.
- [Side-Effect-Free Equality](https://banes-lab.com/records/lex/side-effect-free-equality.md): The ability to compare value objects by their contents with no side effects.
- [Transactional Consistency Boundary](https://banes-lab.com/records/lex/transactional-consistency-boundary.md): The ability to treat an aggregate as the unit within which invariants hold atomically.
- [Explicit Boundary](https://banes-lab.com/records/lex/explicit-boundary.md): The requirement that a clear boundary separate the domain from external systems it integrates with.
- [Relationship Semantics](https://banes-lab.com/records/lex/relationship-semantics.md): The requirement that each relationship between bounded contexts carry a defined meaning.
- [Stable Identity](https://banes-lab.com/records/lex/stable-identity.md): The requirement that an entity keep one stable identifier throughout its lifetime.
- [Value Equality](https://banes-lab.com/records/lex/value-equality.md): The requirement that two value objects be treated as equal when all their attributes match.
- [Translation Model](https://banes-lab.com/records/lex/translation-model.md): A mapping between an external system's concepts and the domain's own, keeping the two vocabularies separate.
- [Aggregate Size](https://banes-lab.com/records/lex/aggregate-size.md): The degree to which enlarging an aggregate to enforce invariants increases contention and load on it.
- [Cross-Context Reuse](https://banes-lab.com/records/lex/cross-context-reuse.md): The degree to which isolating each context's model limits reusing models across contexts.
- [Documentation Overhead](https://banes-lab.com/records/lex/documentation-overhead.md): The degree of ongoing effort to document and maintain the map of relationships between contexts.
- [Domain Purity](https://banes-lab.com/records/lex/domain-purity.md): The degree to which the domain model stays free of external and infrastructure concerns.
- [Integration Clarity](https://banes-lab.com/records/lex/integration-clarity.md): The degree to which relationships between contexts are made explicit and understandable.
- [Object Count](https://banes-lab.com/records/lex/object-count.md): The degree to which modeling many concepts as distinct value objects increases the number of objects.
- [Persistence Simplicity](https://banes-lab.com/records/lex/persistence-simplicity.md): The degree to which a rich domain model complicates straightforward mapping to storage.
- [Simple CRUD](https://banes-lab.com/records/lex/simple-crud.md): The degree to which a full domain model adds overhead where simple create-read-update-delete would suffice.
- [All-Or-Nothing Failure](https://banes-lab.com/records/lex/all-or-nothing-failure.md): Failing the entire system when one part fails instead of degrading to reduced but working service.
- [Brittle Architecture](https://banes-lab.com/records/lex/brittle-architecture.md): A fragile design that breaks entirely under any condition it was not explicitly built for.
- [Exception Swallowing](https://banes-lab.com/records/lex/exception-swallowing.md): Catching an exception and silently discarding it, hiding the failure from callers and logs.
- [Fail Open](https://banes-lab.com/records/lex/fail-open.md): Granting access or continuing when a security check fails, exposing the system on error.
- [Failure Propagation](https://banes-lab.com/records/lex/failure-propagation.md): Letting a failure spread unchecked across component boundaries instead of containing it.
- [Fragile Parsing](https://banes-lab.com/records/lex/fragile-parsing.md): Parsing input so rigidly that any minor deviation causes a failure.
- [Infinite Wait](https://banes-lab.com/records/lex/infinite-wait.md): Waiting indefinitely for an operation that may never complete, tying up resources.
- [Non-Idempotent Operation](https://banes-lab.com/records/lex/non-idempotent-operation.md): An operation whose repetition changes the result, making it unsafe to retry.
- [Shared Resource Pool](https://banes-lab.com/records/lex/shared-resource-pool.md): Serving all work from one shared resource pool, so one overloaded consumer starves the rest.
- [Single Behavior Path](https://banes-lab.com/records/lex/single-behavior-path.md): Providing only one execution path with no fallback, so any failure in it fails the whole request.
- [Trusting Invalid Inputs](https://banes-lab.com/records/lex/trusting-invalid-inputs.md): Assuming inputs are valid and using them without checking, so bad data flows through unguarded.
- [Unbounded Ingestion](https://banes-lab.com/records/lex/unbounded-ingestion.md): Accepting incoming work with no limit, so a fast producer overwhelms a slower consumer.
- [Unbounded Retry](https://banes-lab.com/records/lex/unbounded-retry.md): Retrying a failing operation endlessly with no limit, amplifying load and delaying recovery.
- [Unsafe Default Continuation](https://banes-lab.com/records/lex/unsafe-default-continuation.md): Continuing in an unsafe default state after a failure instead of stopping in a safe one.
- [Blast-Radius Reduction](https://banes-lab.com/records/lex/blast-radius-reduction.md): The ability to contain a failure so it affects only one isolated partition.
- [Bounded Waiting](https://banes-lab.com/records/lex/bounded-waiting.md): The ability to guarantee an operation waits no longer than a set limit.
- [Cascading Failure Prevention](https://banes-lab.com/records/lex/cascading-failure-prevention.md): The ability to stop one component's failure from cascading through its callers.
- [Continued Operation Under Failure](https://banes-lab.com/records/lex/continued-operation-under-failure.md): The ability to keep operating correctly despite the failure of some components.
- [Controlled Failure](https://banes-lab.com/records/lex/controlled-failure.md): The ability to fail in a defined, handled way rather than crashing unpredictably.
- [Deny-by-Default Behavior](https://banes-lab.com/records/lex/deny-by-default-behavior.md): The ability to default to denying access when a security check cannot complete.
- [Early Defect Detection](https://banes-lab.com/records/lex/early-defect-detection.md): The ability to surface a defect immediately at its source rather than letting it propagate.
- [Localized Recovery](https://banes-lab.com/records/lex/localized-recovery.md): The ability to recover from a failure within its boundary without restarting the whole system.
- [Overload Protection](https://banes-lab.com/records/lex/overload-protection.md): The ability to protect a system from being overwhelmed by shedding or slowing incoming load.
- [Safe Failure](https://banes-lab.com/records/lex/safe-failure.md): The ability to fail without corrupting state or causing further damage.
- [Stability Under Stress](https://banes-lab.com/records/lex/stability-under-stress.md): The ability to keep functioning under load spikes and adverse conditions.
- [Transient Failure Recovery](https://banes-lab.com/records/lex/transient-failure-recovery.md): The ability to recover from short-lived failures by retrying the operation.
- [Backoff](https://banes-lab.com/records/lex/backoff.md): Progressively increasing the wait between retries to avoid overwhelming a recovering dependency.
- [Error Model](https://banes-lab.com/records/lex/error-model.md): A structured representation of the kinds of errors a system can raise and how they are categorized.
- [Alternate Behavior](https://banes-lab.com/records/lex/alternate-behavior.md): The requirement that a defined alternate behavior exist to use when the primary path fails.
- [Capacity Signaling](https://banes-lab.com/records/lex/capacity-signaling.md): The requirement that downstream capacity be signaled upstream so producers adjust their rate.
- [Failure Isolation](https://banes-lab.com/records/lex/failure-isolation.md): The requirement that a failure be contained within a boundary so it cannot spread.
- [Failure Threshold](https://banes-lab.com/records/lex/failure-threshold.md): The requirement of a defined failure count or rate at which a circuit breaker trips.
- [Feature Isolation](https://banes-lab.com/records/lex/feature-isolation.md): The requirement that individual features be isolated so one can be disabled without taking down others.
- [Resource Isolation](https://banes-lab.com/records/lex/resource-isolation.md): The requirement that resources be partitioned so exhaustion in one pool cannot starve others.
- [Strict Output](https://banes-lab.com/records/lex/strict-output.md): The requirement that a component emit only strictly conformant, well-formed output.
- [Timeout](https://banes-lab.com/records/lex/timeout.md): The requirement that an operation be given a maximum time to complete before being abandoned.
- [Tolerant Input](https://banes-lab.com/records/lex/tolerant-input.md): The requirement that a component accept and cope with input that deviates from the ideal format.
- [Availability of Degraded Dependency](https://banes-lab.com/records/lex/availability-of-degraded-dependency.md): The degree to which tripping a breaker to protect the system also cuts off a still-partly-working dependency.
- [Consistency / Feature Completeness](https://banes-lab.com/records/lex/consistency-feature-completeness.md): The degree to which serving reduced functionality during failure sacrifices full consistency or completeness.
- [Hidden Errors](https://banes-lab.com/records/lex/hidden-errors.md): The degree to which catching failures at a boundary can obscure the underlying errors from view.
- [Load Amplification](https://banes-lab.com/records/lex/load-amplification.md): The degree to which retrying failed operations multiplies load on an already-struggling dependency.
- [Slow Operation Tolerance](https://banes-lab.com/records/lex/slow-operation-tolerance.md): The degree to which enforcing timeouts sacrifices tolerance for legitimately slow operations.
- [Stability](https://banes-lab.com/records/lex/stability.md): The degree to which a system keeps operating steadily without collapsing under load.
- [Stale/Reduced Results](https://banes-lab.com/records/lex/stale-reduced-results.md): The degree to which serving a fallback yields stale or reduced-quality results.
- [Strict Validation](https://banes-lab.com/records/lex/strict-validation.md): The degree to which rejecting deviant input conflicts with accepting it tolerantly.
- [Verbosity](https://banes-lab.com/records/lex/verbosity.md): The degree to which pervasive defensive checks add verbosity and clutter to the code.
- [Blocking Synchronous Chains](https://banes-lab.com/records/lex/blocking-synchronous-chains.md): Chaining services through blocking synchronous calls, so one slow link stalls the entire request.
- [CRUD-Only State Persistence](https://banes-lab.com/records/lex/crud-only-state-persistence.md): Persisting only current state via create-read-update-delete, discarding the history that event sourcing preserves.
- [Direct Event Handler Calls](https://banes-lab.com/records/lex/direct-event-handler-calls.md): Invoking event handlers by direct method call, coupling emitter to handler and defeating the event bus.
- [Direct Point-to-Point Calls](https://banes-lab.com/records/lex/direct-point-to-point-calls.md): Wiring services together with direct point-to-point calls, coupling each sender to specific receivers.
- [Duplicate Side Effects](https://banes-lab.com/records/lex/duplicate-side-effects.md): Reprocessing a message so its side effects run more than once, corrupting state when not idempotent.
- [Global ACID Transaction](https://banes-lab.com/records/lex/global-acid-transaction.md): Attempting a single ACID transaction spanning multiple distributed services, creating tight coupling and availability loss.
- [Hidden Temporal Coupling](https://banes-lab.com/records/lex/hidden-temporal-coupling.md): An undocumented ordering requirement between operations that must run in a specific sequence to work correctly.
- [In-Memory Direct Invocation](https://banes-lab.com/records/lex/in-memory-direct-invocation.md): Calling a component directly in-process where a durable queue is needed, losing buffering and delivery guarantees.
- [In-Place Mutation](https://banes-lab.com/records/lex/in-place-mutation.md): Overwriting existing records in place where an append-only log is required, destroying history.
- [Infinite Redelivery Loop](https://banes-lab.com/records/lex/infinite-redelivery-loop.md): Endlessly redelivering a failing message with no dead-letter path, blocking the queue indefinitely.
- [Infrastructure Events in Domain](https://banes-lab.com/records/lex/infrastructure-events-in-domain.md): Leaking infrastructure or technical events into the domain model, polluting it with concerns it should not hold.
- [Internal Domain Event Leakage](https://banes-lab.com/records/lex/internal-domain-event-leakage.md): Exposing internal domain events to external consumers, coupling them to private model details.
- [Irreversible Side Effects](https://banes-lab.com/records/lex/irreversible-side-effects.md): Performing side effects that cannot be undone within a workflow that may need to roll back.
- [Mutable State Only](https://banes-lab.com/records/lex/mutable-state-only.md): Keeping only mutable current state with no event record, so past states and changes cannot be recovered.
- [Point-to-Point Coupling](https://banes-lab.com/records/lex/point-to-point-coupling.md): Coupling a sender directly to a specific receiver, so adding a consumer requires changing the sender.
- [Shared Database](https://banes-lab.com/records/lex/shared-database.md): Multiple services reading and writing one shared database, coupling them and destroying service autonomy.
- [Single Serial Consumer](https://banes-lab.com/records/lex/single-serial-consumer.md): Processing a queue with one consumer in series, so throughput cannot scale with load.
- [Unified CRUD Model](https://banes-lab.com/records/lex/unified-crud-model.md): Using one shared model for both reads and writes, preventing each from being optimized for its purpose.
- [Broker/Event Bus](https://banes-lab.com/records/lex/broker-event-bus.md): A runtime intermediary that routes messages between publishers and subscribers.
- [Command/Query Separation](https://banes-lab.com/records/lex/command-query-separation.md): Separating operations that change state from those that return data, so each method has a single purpose.
- [Compensating Transactions](https://banes-lab.com/records/lex/compensating-transactions.md): Undoing a completed step's effects with an offsetting action when a later step in a distributed workflow fails.
- [Consumer](https://banes-lab.com/records/lex/consumer.md): A component that receives and processes messages from a queue or topic.
- [Deduplication Key](https://banes-lab.com/records/lex/deduplication-key.md): A stable identifier attached to a message that lets a consumer detect and drop duplicates.
- [Event Contract](https://banes-lab.com/records/lex/event-contract.md): The agreed schema and semantics of an event that publishers and subscribers both honor.
- [Event Schema](https://banes-lab.com/records/lex/event-schema.md): A formal definition of the structure and fields of an event's payload.
- [Event Semantics](https://banes-lab.com/records/lex/event-semantics.md): The agreed meaning of what an event represents and the conditions under which it is emitted.
- [Events](https://banes-lab.com/records/lex/events.md): Records of things that have happened in a system, emitted for other components to react to.
- [Immutable Events](https://banes-lab.com/records/lex/immutable-events.md): The requirement that recorded events never change once written, only be appended to.
- [Local Transaction](https://banes-lab.com/records/lex/local-transaction.md): A transaction confined to a single service's own datastore, the atomic unit a saga or outbox composes.
- [Message Queue/Topics](https://banes-lab.com/records/lex/message-queue-topics.md): The durable queues and topics through which a broker routes messages to consumers.
- [Message Relay](https://banes-lab.com/records/lex/message-relay.md): A component that reads pending messages from an outbox and publishes them to the broker.
- [Ordered Log](https://banes-lab.com/records/lex/ordered-log.md): An append-only sequence of records that preserves the order in which they were written.
- [Own Data](https://banes-lab.com/records/lex/own-data.md): The requirement that each service alone own and control its data store.
- [Publisher](https://banes-lab.com/records/lex/publisher.md): A component that emits messages to a topic or bus for subscribers to receive.
- [Reconciliation](https://banes-lab.com/records/lex/reconciliation.md): The activity of detecting and resolving divergence between replicas so they converge to a consistent state.
- [Retry](https://banes-lab.com/records/lex/retry.md): Re-attempting a failed operation, typically after a delay, to overcome a transient fault.
- [Reversible/Compensable Step](https://banes-lab.com/records/lex/reversible-compensable-step.md): The requirement that each step in a distributed workflow can be undone by a compensating action.
- [Routing](https://banes-lab.com/records/lex/routing.md): The ability to direct each message to its correct destination based on topic, key, or rule.
- [Subscriber](https://banes-lab.com/records/lex/subscriber.md): A component that registers interest in a topic and receives its messages.
- [Subscriber Model](https://banes-lab.com/records/lex/subscriber-model.md): A representation of which consumers subscribe to which topics and how they receive messages.
- [User Expectations](https://banes-lab.com/records/lex/user-expectations.md): The behavior users assume a system will exhibit, such as seeing their own writes immediately.
- [Asynchronous Processing](https://banes-lab.com/records/lex/asynchronous-processing.md): The ability to handle work without blocking the caller, decoupling request from completion.
- [Atomic State Change + Message Publish](https://banes-lab.com/records/lex/atomic-state-change-message-publish.md): The ability to commit a state change and publish its corresponding message as one atomic unit.
- [Consumer Elasticity](https://banes-lab.com/records/lex/consumer-elasticity.md): The ability to add or remove consumers dynamically to match message volume.
- [Cross-Service Communication](https://banes-lab.com/records/lex/cross-service-communication.md): The ability for independent services to exchange information without direct coupling.
- [Decoupled Domain Reactions](https://banes-lab.com/records/lex/decoupled-domain-reactions.md): The ability for domain logic to react to events without the emitter knowing its consumers.
- [Decoupled Event Distribution](https://banes-lab.com/records/lex/decoupled-event-distribution.md): The ability to distribute events to many consumers without the source depending on any of them.
- [Distributed Autonomy](https://banes-lab.com/records/lex/distributed-autonomy.md): The ability for distributed nodes to operate and decide independently without central coordination.
- [Failure Recovery](https://banes-lab.com/records/lex/failure-recovery.md): The ability to restore correct operation after a failure through compensation or retry.
- [Fan-Out Notification](https://banes-lab.com/records/lex/fan-out-notification.md): The ability to deliver one event to many interested subscribers at once.
- [Historical Reconstruction](https://banes-lab.com/records/lex/historical-reconstruction.md): The ability to rebuild past state by replaying the recorded sequence of events.
- [Long-Running Transactions](https://banes-lab.com/records/lex/long-running-transactions.md): The ability to carry a business transaction across many steps and a long duration via compensation.
- [Parallel Message Processing](https://banes-lab.com/records/lex/parallel-message-processing.md): The ability for multiple consumers to process messages from the same source at once.
- [Poison-Message Quarantine](https://banes-lab.com/records/lex/poison-message-quarantine.md): The ability to divert a repeatedly-failing message to a separate queue so it stops blocking others.
- [Read/Write Model Optimization](https://banes-lab.com/records/lex/read-write-model-optimization.md): The ability to shape read and write models independently for their differing access patterns.
- [Reprocessing After Fix](https://banes-lab.com/records/lex/reprocessing-after-fix.md): The ability to reprocess quarantined messages once the underlying defect is fixed.
- [Safe Message Redelivery](https://banes-lab.com/records/lex/safe-message-redelivery.md): The ability to redeliver a message without causing duplicate effects, given idempotent handling.
- [Temporal Modeling](https://banes-lab.com/records/lex/temporal-modeling.md): The ability to model how state evolved over time by preserving each change as an event.
- [Temporal Queries](https://banes-lab.com/records/lex/temporal-queries.md): The ability to ask what a system's state was at any past point in time.
- [Work Distribution](https://banes-lab.com/records/lex/work-distribution.md): The ability to spread units of work across many workers via a broker.
- [At-Least-Once Delivery Safety](https://banes-lab.com/records/lex/at-least-once-delivery-safety.md): The degree to which a message is guaranteed to be delivered at least once, tolerating duplicates.
- [Decoupling](https://banes-lab.com/records/lex/decoupling.md): The degree to which components depend on one another minimally, so each can change independently.
- [Event Reliability](https://banes-lab.com/records/lex/event-reliability.md): The degree to which events are guaranteed to be delivered despite failures.
- [Business Complexity](https://banes-lab.com/records/lex/business-complexity.md): The degree of domain intricacy that a coordination mechanism must accommodate.
- [Delivery Ordering](https://banes-lab.com/records/lex/delivery-ordering.md): The degree to which messages are delivered in a defined order, which broad fan-out can weaken.
- [Duplication with Domain Events](https://banes-lab.com/records/lex/duplication-with-domain-events.md): The degree of overlap between integration events and domain events that must be kept in sync.
- [Event Granularity](https://banes-lab.com/records/lex/event-granularity.md): The degree of coarseness or fineness at which events are defined, trading detail against volume.
- [Event Storm / Traceability](https://banes-lab.com/records/lex/event-storm-traceability.md): The degree to which a high volume of events makes end-to-end flows hard to trace.
- [Global Consistency](https://banes-lab.com/records/lex/global-consistency.md): The degree to which all nodes reflect the same state at once, which service autonomy gives up.
- [Immediate Consistency](https://banes-lab.com/records/lex/immediate-consistency.md): The degree to which a read reflects the latest write instantly, which asynchronous processing defers.
- [Operational Dependency](https://banes-lab.com/records/lex/operational-dependency.md): The degree to which a system's operation depends on a message broker remaining available.
- [Query Complexity](https://banes-lab.com/records/lex/query-complexity.md): The degree of difficulty of answering queries when state is stored as an event history rather than current rows.
- [Relay Complexity](https://banes-lab.com/records/lex/relay-complexity.md): The degree of added complexity of running a relay process that forwards messages from an outbox.
- [State Overhead](https://banes-lab.com/records/lex/state-overhead.md): The degree of extra state a consumer must retain to deduplicate or order messages.
- [Storage Growth](https://banes-lab.com/records/lex/storage-growth.md): The degree to which an append-only log's storage footprint grows unbounded over time.
- [Storage Volume](https://banes-lab.com/records/lex/storage-volume.md): The degree to which retaining a full event stream consumes large amounts of storage.
- [Strong Consistency](https://banes-lab.com/records/lex/strong-consistency.md): The degree to which all reads see the latest write, which event-driven asynchrony relaxes.
- [Strong Immediate Consistency](https://banes-lab.com/records/lex/strong-immediate-consistency.md): The degree to which every read reflects the most recent write without delay, which eventual consistency relaxes.
- [Workflow Complexity](https://banes-lab.com/records/lex/workflow-complexity.md): The degree of intricacy of coordinating a multi-step distributed workflow.
- [Excessive Configuration](https://banes-lab.com/records/lex/excessive-configuration.md): Requiring explicit configuration for everything instead of relying on sensible conventions.
- [Hardcoded Behavior](https://banes-lab.com/records/lex/hardcoded-behavior.md): Hardcoding behavior in code instead of driving it from declarative metadata.
- [Hardcoded Registration](https://banes-lab.com/records/lex/hardcoded-registration.md): Registering components with hardcoded wiring instead of declaring them in a manifest.
- [Hidden Runtime Behavior](https://banes-lab.com/records/lex/hidden-runtime-behavior.md): Behavior that is opaque at runtime because the system does not describe its own structure.
- [Implicit Capability](https://banes-lab.com/records/lex/implicit-capability.md): Leaving what a component can do implicit and undiscoverable instead of declaring it.
- [Opaque API](https://banes-lab.com/records/lex/opaque-api.md): An API that does not describe itself, so clients must rely on external, out-of-band documentation.
- [Opaque Binary/Untyped Structures](https://banes-lab.com/records/lex/opaque-binary-untyped-structures.md): Using opaque binary or untyped data that carries no description of its own structure.
- [Client Generation](https://banes-lab.com/records/lex/client-generation.md): The ability to generate client code automatically from an API's self-description.
- [Dynamic Processing](https://banes-lab.com/records/lex/dynamic-processing.md): The ability to process data generically by reading its self-describing structure.
- [HATEOAS-style Navigation](https://banes-lab.com/records/lex/hateoas-style-navigation.md): The ability for clients to navigate an API by following links it returns in its responses.
- [Plugin Loading](https://banes-lab.com/records/lex/plugin-loading.md): The ability to discover and load plugins declared in manifests at runtime.
- [Reduced Boilerplate](https://banes-lab.com/records/lex/reduced-boilerplate.md): The ability to avoid repetitive boilerplate by relying on conventions.
- [Runtime Configuration without Code Change](https://banes-lab.com/records/lex/runtime-configuration-without-code-change.md): The ability to change a system's behavior by editing configuration rather than code.
- [Manifest](https://banes-lab.com/records/lex/manifest.md): A declarative document listing a component's capabilities and metadata.
- [Manifest Schema](https://banes-lab.com/records/lex/manifest-schema.md): A formal definition of the structure a manifest must follow.
- [Metadata Schema](https://banes-lab.com/records/lex/metadata-schema.md): A formal definition of the metadata fields that drive a system's behavior.
- [Explicit Semantics](https://banes-lab.com/records/lex/explicit-semantics.md): The requirement that declarative configuration carry an explicit, defined meaning.
- [Stable Conventions](https://banes-lab.com/records/lex/stable-conventions.md): The requirement that the conventions a system relies on stay stable and well-known.
- [Declaration Drift](https://banes-lab.com/records/lex/declaration-drift.md): The degree to which a declared capability set drifts out of sync with the actual behavior.
- [Dynamic Complexity](https://banes-lab.com/records/lex/dynamic-complexity.md): The degree to which interpreting declarative configuration at runtime adds hidden dynamic complexity.
- [Explicitness](https://banes-lab.com/records/lex/explicitness.md): The degree to which relying on conventions reduces the explicitness of how a system is configured.
- [Manifest Drift](https://banes-lab.com/records/lex/manifest-drift.md): The degree to which a manifest drifts out of sync with the components it declares.
- [Metadata Drift](https://banes-lab.com/records/lex/metadata-drift.md): The degree to which self-describing metadata drifts out of sync with the actual system.
- [Payload Verbosity](https://banes-lab.com/records/lex/payload-verbosity.md): The degree to which embedding self-description in responses enlarges their payloads.
- [Self-Description](https://banes-lab.com/records/lex/self-description.md): The degree to which a component exposes its own capabilities and structure for inspection.
- [Size Overhead](https://banes-lab.com/records/lex/size-overhead.md): The degree to which embedding structural descriptions in data increases its size.
- [Code-as-Data Representation](https://banes-lab.com/records/lex/code-as-data-representation.md): The requirement that a program's code be representable in the same data structures the language manipulates.
- [Macro Systems](https://banes-lab.com/records/lex/macro-systems.md): A facility that lets code transform other code at compile time by operating on its data representation.
- [Opaque Syntax Trees](https://banes-lab.com/records/lex/opaque-syntax-trees.md): Syntax trees a program cannot inspect or manipulate as data, so code cannot be transformed programmatically.
- [AST or Data Representation](https://banes-lab.com/records/lex/ast-or-data-representation.md): The requirement that code be represented as a structured syntax tree or data rather than as raw text.
- [Program Transformation](https://banes-lab.com/records/lex/program-transformation.md): The ability to analyze and rewrite a program by manipulating its structured representation.
- [Safety/Debuggability](https://banes-lab.com/records/lex/safety-debuggability.md): The degree to which treating code as manipulable data can obscure what runs and make it harder to debug.
- [String-Based Code Generation](https://banes-lab.com/records/lex/string-based-code-generation.md): Building code by concatenating strings, so the result is unchecked, injection-prone, and hard to analyze.
- [Boilerplate Elimination](https://banes-lab.com/records/lex/boilerplate-elimination.md): The ability to remove repetitive boilerplate by generating it from a single declaration.
- [Explicit Handwritten Code](https://banes-lab.com/records/lex/explicit-handwritten-code.md): Writing code out by hand explicitly rather than generating it, favoring directness and debuggability over reuse.
- [Reflection/AST/Code Generation](https://banes-lab.com/records/lex/reflection-ast-code-generation.md): The requirement that a language expose reflection, syntax trees, or code generation for programs to manipulate themselves.
- [Performance/Safety](https://banes-lab.com/records/lex/performance-safety.md): The degree to which inspecting and dispatching on types at runtime costs performance and bypasses static safety.
- [Runtime Type Metadata](https://banes-lab.com/records/lex/runtime-type-metadata.md): Type information retained at runtime so a program can inspect the shape of its own values.
- [Diagnostics](https://banes-lab.com/records/lex/diagnostics.md): The ability to inspect a running system's own structure and state to diagnose it.
- [Opaque Runtime](https://banes-lab.com/records/lex/opaque-runtime.md): A runtime that exposes nothing about its own structure, so its components and state cannot be inspected.
- [Self-Describing Systems](https://banes-lab.com/records/lex/self-describing-systems.md): The degree to which a system carries enough metadata to describe its own structure and capabilities at runtime.
- [Build Complexity](https://banes-lab.com/records/lex/build-complexity.md): The degree to which moving work into the build to run at compile time makes the build harder to set up and reason about.
- [Compile-Time Inputs](https://banes-lab.com/records/lex/compile-time-inputs.md): The requirement that the inputs a computation needs be known at compile time so it can run then.
- [Early Error Detection](https://banes-lab.com/records/lex/early-error-detection.md): The ability to catch errors at compile time rather than letting them surface at runtime.
- [Runtime Dynamic Evaluation](https://banes-lab.com/records/lex/runtime-dynamic-evaluation.md): Evaluating code or expressions dynamically at runtime, trading compile-time checking for runtime flexibility.
- [Dynamic Optimization/Adaptation](https://banes-lab.com/records/lex/dynamic-optimization-adaptation.md): The ability to generate specialized code at runtime to optimize or adapt to observed conditions.
- [Safe Generation Boundary](https://banes-lab.com/records/lex/safe-generation-boundary.md): The requirement that runtime code generation be confined to a safe, sandboxed boundary away from untrusted input.
- [Security/Debugging](https://banes-lab.com/records/lex/security-debugging.md): The degree to which generating and running code at runtime widens the attack surface and complicates debugging.
- [Domain Expressiveness](https://banes-lab.com/records/lex/domain-expressiveness.md): The ability to express domain rules directly in terms a domain expert recognizes.
- [Formal Grammar/Semantics](https://banes-lab.com/records/lex/formal-grammar-semantics.md): The requirement that a domain language have a defined grammar and semantics rather than an ad-hoc syntax.
- [General-Purpose Boilerplate](https://banes-lab.com/records/lex/general-purpose-boilerplate.md): Expressing domain logic through verbose general-purpose code and its boilerplate instead of a concise domain notation.
- [Tooling/Maintenance](https://banes-lab.com/records/lex/tooling-maintenance.md): The degree to which owning a custom language burdens a team with building and maintaining its tooling.
- [Code Generation or Interpreters](https://banes-lab.com/records/lex/code-generation-or-interpreters.md): The requirement that a domain language be backed by a generator or interpreter that executes it.
- [Domain Modeling](https://banes-lab.com/records/lex/domain-modeling.md): Expressing a problem domain as a first-class language of its own concepts and rules.
- [High-Level Domain Expression](https://banes-lab.com/records/lex/high-level-domain-expression.md): The ability to express solutions in high-level domain terms rather than low-level general-purpose code.
- [One-Size General-Purpose Code](https://banes-lab.com/records/lex/one-size-general-purpose-code.md): Expressing every domain in a single general-purpose language, rather than in domain-specific notations.
- [Toolchain Complexity](https://banes-lab.com/records/lex/toolchain-complexity.md): The degree to which building custom languages adds compilers, parsers, and editors to a project's toolchain.
- [Formal Model](https://banes-lab.com/records/lex/formal-model.md): A precise, machine-processable model of a system from which implementations are generated.
- [Generated Implementations](https://banes-lab.com/records/lex/generated-implementations.md): Implementation code produced automatically from a model rather than written by hand.
- [Handwritten Divergence](https://banes-lab.com/records/lex/handwritten-divergence.md): Hand-editing generated code so it drifts from the model it came from, breaking regeneration.
- [Transformation Rules](https://banes-lab.com/records/lex/transformation-rules.md): The requirement that explicit rules define how a model maps to generated implementation code.
- [Ad-Hoc Notebook-to-Production](https://banes-lab.com/records/lex/ad-hoc-notebook-to-production.md): Promoting exploratory notebook code straight to production without engineering it into a reliable pipeline.
- [Deploy-and-Forget Models](https://banes-lab.com/records/lex/deploy-and-forget-models.md): Deploying a model and never monitoring it, so degradation as the data drifts goes unnoticed.
- [Exact Keyword Search Only](https://banes-lab.com/records/lex/exact-keyword-search-only.md): Relying solely on exact keyword matching for retrieval, missing semantically related results.
- [Flat Document-Only Knowledge](https://banes-lab.com/records/lex/flat-document-only-knowledge.md): Representing knowledge as unlinked flat documents, losing the relationships a graph would capture.
- [Opaque Black-Box Decisions](https://banes-lab.com/records/lex/opaque-black-box-decisions.md): Producing model decisions with no explanation, so their reasoning cannot be inspected or trusted.
- [Opaque Ungoverned Model Use](https://banes-lab.com/records/lex/opaque-ungoverned-model-use.md): Using models with no governance or oversight, leaving their behavior and risks unmanaged.
- [Training-Time-Only Model Logic](https://banes-lab.com/records/lex/training-time-only-model-logic.md): Building logic that exists only during training, with no counterpart to serve predictions at inference.
- [Unapproved Model Deployment](https://banes-lab.com/records/lex/unapproved-model-deployment.md): Deploying a model to production without passing the required review and approval gates.
- [Ungrounded Generation](https://banes-lab.com/records/lex/ungrounded-generation.md): Generating output from a model alone without grounding it in retrieved facts, inviting hallucination.
- [Unguarded Model Autonomy](https://banes-lab.com/records/lex/unguarded-model-autonomy.md): Letting a model act autonomously with no safety guardrails on what it can do.
- [Untested Model Deployment](https://banes-lab.com/records/lex/untested-model-deployment.md): Deploying a model without evaluating it, so its real-world quality is unknown until it fails.
- [Approval Policy](https://banes-lab.com/records/lex/approval-policy.md): The declared rules and gates a model must pass before it may be deployed.
- [Document Store](https://banes-lab.com/records/lex/document-store.md): The body of documents a retrieval system searches to ground a model's generation.
- [Data Pipeline](https://banes-lab.com/records/lex/data-pipeline.md): The stages that ingest, clean, and transform data into a form suitable for training or inference.
- [Data/Model Boundaries](https://banes-lab.com/records/lex/data-model-boundaries.md): The lines separating data preparation, model training, and serving so each concern stays isolated.
- [Dataset](https://banes-lab.com/records/lex/dataset.md): A curated collection of examples used to train or evaluate a model.
- [Embeddings](https://banes-lab.com/records/lex/embeddings.md): Numeric vector representations of data that place semantically similar items near each other.
- [Entities](https://banes-lab.com/records/lex/entities.md): The distinct things, such as people, places or concepts, that a knowledge graph represents as nodes.
- [Grounding Strategy](https://banes-lab.com/records/lex/grounding-strategy.md): A scheme for anchoring a model's output in retrieved, authoritative sources rather than its parameters alone.
- [Guardrails](https://banes-lab.com/records/lex/guardrails.md): Constraints and filters that bound what a model is permitted to output or do at runtime.
- [Input/Output Contract](https://banes-lab.com/records/lex/input-output-contract.md): The agreed schema of the inputs a model accepts and the outputs it returns.
- [Model Artifact](https://banes-lab.com/records/lex/model-artifact.md): The trained model file, with its learned weights, that is loaded to serve predictions.
- [Model Registry](https://banes-lab.com/records/lex/model-registry.md): A catalog that tracks model versions, their metadata, and their deployment status.
- [Rationale/Evidence](https://banes-lab.com/records/lex/rationale-evidence.md): The reasons and supporting evidence recorded for a model's decision.
- [Relations](https://banes-lab.com/records/lex/relations.md): The typed connections between entities that a knowledge graph represents as edges.
- [Retriever](https://banes-lab.com/records/lex/retriever.md): A component that finds and returns the most relevant documents for a query.
- [Schema/Ontology](https://banes-lab.com/records/lex/schema-ontology.md): A formal definition of the entity types and relationship types a knowledge graph may contain.
- [Tool Interface](https://banes-lab.com/records/lex/tool-interface.md): The defined contract through which an agent invokes external tools and receives their results.
- [Training/Inference Separation](https://banes-lab.com/records/lex/training-inference-separation.md): The requirement that model training and prediction serving be distinct, separately-managed phases.
- [Vector Index](https://banes-lab.com/records/lex/vector-index.md): A data structure that organizes embedding vectors for fast nearest-neighbor lookup.
- [Retraining Triggers](https://banes-lab.com/records/lex/retraining-triggers.md): Signals that automatically initiate model retraining when measured drift crosses a threshold.
- [Model-Integrated Systems](https://banes-lab.com/records/lex/model-integrated-systems.md): The ability of a software system to incorporate models as integral parts of its behavior.
- [Audit and Debugging](https://banes-lab.com/records/lex/audit-and-debugging.md): The ability to inspect and trace a model's decisions for auditing and debugging.
- [Bounded Tool-Using Agents](https://banes-lab.com/records/lex/bounded-tool-using-agents.md): The ability to run agents that use external tools within defined, safe limits.
- [Contextual Generation](https://banes-lab.com/records/lex/contextual-generation.md): The ability to generate output informed by retrieved, task-specific context.
- [Controlled Model Deployment](https://banes-lab.com/records/lex/controlled-model-deployment.md): The ability to release models through a governed, approved process.
- [Degradation Detection](https://banes-lab.com/records/lex/degradation-detection.md): The ability to detect when a model's accuracy declines as data shifts.
- [Governed Autonomy](https://banes-lab.com/records/lex/governed-autonomy.md): The ability to let an agent act autonomously within enforced governance limits.
- [Model Selection/Regression Detection](https://banes-lab.com/records/lex/model-selection-regression-detection.md): The ability to compare models and catch quality regressions before deployment.
- [Relationship-Aware Retrieval/Reasoning](https://banes-lab.com/records/lex/relationship-aware-retrieval-reasoning.md): The ability to retrieve and reason over the relationships between entities, not just isolated facts.
- [Reliable Model Lifecycle](https://banes-lab.com/records/lex/reliable-model-lifecycle.md): The ability to manage a model's data, training, deployment and monitoring reliably and repeatably.
- [Runtime Prediction/Generation](https://banes-lab.com/records/lex/runtime-prediction-generation.md): The ability to produce predictions or generated output from a trained model at runtime.
- [Safe Model Deployment](https://banes-lab.com/records/lex/safe-model-deployment.md): The ability to deploy models with safeguards that bound their behavior.
- [Semantic Search](https://banes-lab.com/records/lex/semantic-search.md): The ability to find results by meaning and similarity rather than exact keyword match.
- [Similarity Retrieval](https://banes-lab.com/records/lex/similarity-retrieval.md): The ability to retrieve items nearest to a query in an embedding space.
- [Structured, Versioned Prompts](https://banes-lab.com/records/lex/structured-versioned-prompts.md): Prompts authored as structured, version-controlled artifacts rather than ad-hoc strings.
- [Knowledge Freshness](https://banes-lab.com/records/lex/knowledge-freshness.md): The degree to which a system's knowledge reflects current rather than stale information.
- [Trust](https://banes-lab.com/records/lex/trust.md): The degree to which users are willing to rely on a system's outputs.
- [Capability/Utility](https://banes-lab.com/records/lex/capability-utility.md): The degree of usefulness a model offers, which strict safety limits can constrain.
- [Curation Cost](https://banes-lab.com/records/lex/curation-cost.md): The degree of ongoing effort required to build and maintain a curated knowledge graph.
- [Experiment Velocity](https://banes-lab.com/records/lex/experiment-velocity.md): The rate at which model experiments can be run and iterated, which governance can slow.
- [Experimentation Speed](https://banes-lab.com/records/lex/experimentation-speed.md): The rate at which new modeling ideas can be tried and evaluated.
- [Explainability/Recall](https://banes-lab.com/records/lex/explainability-recall.md): The degree to which retrieval stays explainable and complete, traded against pure similarity ranking.
- [Latency/Cost](https://banes-lab.com/records/lex/latency-cost.md): The degree of latency and expense incurred to serve model predictions.
- [Metric Completeness](https://banes-lab.com/records/lex/metric-completeness.md): The degree to which evaluation metrics capture every dimension of a model's quality.
- [Model Complexity](https://banes-lab.com/records/lex/model-complexity.md): The degree of intricacy in a model, which raises accuracy but lowers explainability.
- [Monitoring Cost](https://banes-lab.com/records/lex/monitoring-cost.md): The degree of ongoing expense of continuously monitoring a deployed model.
- [Retrieval Quality/Latency](https://banes-lab.com/records/lex/retrieval-quality-latency.md): The degree to which retrieval must trade result quality against speed.
- [Cost/Noise](https://banes-lab.com/records/lex/cost-noise.md): The degree to which collecting more telemetry adds cost and noise that can obscure the signals that matter.
- [Incident Diagnosis](https://banes-lab.com/records/lex/incident-diagnosis.md): The ability to diagnose the cause of an incident from a system's observable signals.
- [Logs](https://banes-lab.com/records/lex/logs.md): A record of discrete, timestamped events a system emits about what it did.
- [Opaque System](https://banes-lab.com/records/lex/opaque-system.md): A system that exposes no usable signals about its internal state, so failures cannot be understood from outside.
- [Traces](https://banes-lab.com/records/lex/traces.md): A record of the path and timing of a request as it moves through a system's components.
- [Incident Analysis](https://banes-lab.com/records/lex/incident-analysis.md): The ability to reconstruct and analyze an incident from the events a system logged.
- [Noise/Personal Data Leakage](https://banes-lab.com/records/lex/noise-personal-data-leakage.md): The degree to which verbose logging adds noise and risks leaking personal or sensitive data.
- [Structured Events](https://banes-lab.com/records/lex/structured-events.md): Log entries emitted as structured, machine-parsable records rather than free-form text.
- [Alert Noise](https://banes-lab.com/records/lex/alert-noise.md): The degree to which monitoring many signals generates alerts that drown out the meaningful ones.
- [Blind Operation](https://banes-lab.com/records/lex/blind-operation.md): Running a system in production with no monitoring, so problems are noticed only when users report them.
- [Failure Detection](https://banes-lab.com/records/lex/failure-detection.md): The ability to detect that a system has failed or degraded by watching its monitored signals.
- [Alert Fatigue](https://banes-lab.com/records/lex/alert-fatigue.md): The degree to which too many alerts desensitize responders, so the ones that matter are ignored.
- [Incident Response](https://banes-lab.com/records/lex/incident-response.md): Detecting, triaging, and resolving an operational incident once an alert fires.
- [Timely Intervention](https://banes-lab.com/records/lex/timely-intervention.md): The ability to intervene on a problem quickly by being alerted the moment it arises.
- [Accountability](https://banes-lab.com/records/lex/accountability.md): The ability to attribute every consequential action to the actor responsible for it.
- [Opaque Mutation](https://banes-lab.com/records/lex/opaque-mutation.md): Changing state with no record of who changed what or when, so the change cannot be audited.
- [Storage/Privacy](https://banes-lab.com/records/lex/storage-privacy.md): The degree to which retaining a full audit history grows storage and raises privacy concerns.
- [Action](https://banes-lab.com/records/lex/action.md): A field of an audit record identifying the operation that was performed.
- [Actor](https://banes-lab.com/records/lex/actor.md): A field of an audit record identifying who or what performed an action.
- [Forensics](https://banes-lab.com/records/lex/forensics.md): The ability to reconstruct after the fact what happened from an immutable audit record.
- [Privacy](https://banes-lab.com/records/lex/privacy.md): The degree to which a system limits the collection and exposure of personal or sensitive information.
- [Target](https://banes-lab.com/records/lex/target.md): A field of an audit record identifying the resource an action was performed on.
- [Timestamp](https://banes-lab.com/records/lex/timestamp.md): A field of an audit record marking when an action occurred.
- [Untracked Mutation](https://banes-lab.com/records/lex/untracked-mutation.md): Mutating state without writing an audit entry, so the change leaves no trace.
- [Anonymous Flow](https://banes-lab.com/records/lex/anonymous-flow.md): Data or requests flowing through a system with no identifiers, so their path cannot be reconstructed.
- [End-to-End Causality](https://banes-lab.com/records/lex/end-to-end-causality.md): The ability to follow a request's cause-and-effect chain across every component it touches.
- [Logs/Traces](https://banes-lab.com/records/lex/logs-traces.md): The combined log and trace records that let a request be followed from end to end.
- [Metadata Propagation Overhead](https://banes-lab.com/records/lex/metadata-propagation-overhead.md): The degree to which carrying trace metadata through every call adds size and processing cost.
- [Context Propagation](https://banes-lab.com/records/lex/context-propagation.md): The requirement that request context be carried across service boundaries so related calls can be correlated.
- [Header/Metadata Management](https://banes-lab.com/records/lex/header-metadata-management.md): The degree to which threading correlation identifiers through headers adds handling to every call.
- [Request-Level Traceability](https://banes-lab.com/records/lex/request-level-traceability.md): The ability to trace all work belonging to one request by a shared correlation identifier.
- [Uncorrelated Events](https://banes-lab.com/records/lex/uncorrelated-events.md): Emitting events with no shared identifier, so those belonging to one request cannot be tied together.
- [Audit Trail](https://banes-lab.com/records/lex/audit-trail.md): A chronological record linking each event to the one that caused it.
- [Cause-Effect Reconstruction](https://banes-lab.com/records/lex/cause-effect-reconstruction.md): The ability to reconstruct which event triggered which by following causation identifiers.
- [Event Metadata](https://banes-lab.com/records/lex/event-metadata.md): Descriptive fields attached to an event, such as its identifiers, timestamps, and causation links.
- [Metadata Verbosity](https://banes-lab.com/records/lex/metadata-verbosity.md): The degree to which stamping every event with causation metadata makes the event payload verbose.
- [Unlinked Events](https://banes-lab.com/records/lex/unlinked-events.md): Recording events with no link to their cause, so cause-and-effect chains cannot be rebuilt.
- [Latency/Failure Root Cause Analysis](https://banes-lab.com/records/lex/latency-failure-root-cause-analysis.md): The ability to pinpoint which service caused a request's latency or failure by tracing it across hops.
- [Opaque Distributed Calls](https://banes-lab.com/records/lex/opaque-distributed-calls.md): Calls crossing service boundaries with no tracing, so a request's path and bottlenecks are invisible.
- [Overhead/Sampling](https://banes-lab.com/records/lex/overhead-sampling.md): The degree to which tracing every request adds overhead, forcing sampling that can miss rare cases.
- [Trace Context Propagation](https://banes-lab.com/records/lex/trace-context-propagation.md): The requirement that trace identifiers be propagated across every hop of a distributed request.
- [Error-Budget Decisions](https://banes-lab.com/records/lex/error-budget-decisions.md): The ability to decide how much risk to take by spending against a defined reliability error budget.
- [Feature Velocity](https://banes-lab.com/records/lex/feature-velocity.md): The degree to which holding to strict reliability targets limits how fast new features can ship.
- [Objective Reliability Targets](https://banes-lab.com/records/lex/objective-reliability-targets.md): The requirement that reliability be expressed as objective, measurable targets rather than vague aspirations.
- [Vague Reliability Goals](https://banes-lab.com/records/lex/vague-reliability-goals.md): Stating reliability aims in vague, unmeasurable terms, so no check can tell whether they are met.
- [At-a-Glance System Health](https://banes-lab.com/records/lex/at-a-glance-system-health.md): The ability to see a system's overall health at a glance from a consolidated visual display.
- [Dashboard Sprawl](https://banes-lab.com/records/lex/dashboard-sprawl.md): The degree to which unchecked creation of dashboards scatters attention across too many redundant views.
- [Log-Grep-Only Diagnosis](https://banes-lab.com/records/lex/log-grep-only-diagnosis.md): Diagnosing problems solely by grepping raw logs, with no aggregated view of system health.
- [Trend Visibility](https://banes-lab.com/records/lex/trend-visibility.md): The ability to see how a metric is trending over time from a visualized history.
- [Closed Core](https://banes-lab.com/records/lex/closed-core.md): A core that cannot be extended without modifying its own source, so every addition edits the core.
- [Direct Control Ownership](https://banes-lab.com/records/lex/direct-control-ownership.md): Application code driving the overall control flow itself instead of ceding it to a framework or container.
- [Direct Reference](https://banes-lab.com/records/lex/direct-reference.md): Referring to a specific implementation directly instead of looking it up through a registry.
- [Hardcoded Branch Constant](https://banes-lab.com/records/lex/hardcoded-branch-constant.md): Controlling a feature with a hardcoded constant in the code instead of an externally-managed flag.
- [Hardcoded Extensions](https://banes-lab.com/records/lex/hardcoded-extensions.md): Wiring extensions directly into the core so adding one requires editing and rebuilding the core.
- [Hardcoded Instantiation](https://banes-lab.com/records/lex/hardcoded-instantiation.md): Creating dependencies with hardcoded constructors inside a class instead of injecting them.
- [Hardcoded Lookup](https://banes-lab.com/records/lex/hardcoded-lookup.md): Hardcoding a service's address or instance instead of resolving it through a registry.
- [Continuous Delivery](https://banes-lab.com/records/lex/continuous-delivery.md): The ability to release changes to production continuously through an automated pipeline.
- [Decoupled Deploy and Release](https://banes-lab.com/records/lex/decoupled-deploy-and-release.md): The ability to deploy code and separately decide when to activate it for users.
- [Dynamic Lookup](https://banes-lab.com/records/lex/dynamic-lookup.md): The ability to find a registered component by key at runtime.
- [Dynamic Resolution](https://banes-lab.com/records/lex/dynamic-resolution.md): The ability to resolve a service's current location or instance at runtime.
- [Framework Control Flow](https://banes-lab.com/records/lex/framework-control-flow.md): The ability to let a framework drive the overall control flow and call into application code.
- [Gradual Rollout](https://banes-lab.com/records/lex/gradual-rollout.md): The ability to enable a feature for a growing subset of users over time.
- [Late Resolution](https://banes-lab.com/records/lex/late-resolution.md): The ability to defer resolving which implementation to use until the moment it is needed.
- [Mocking](https://banes-lab.com/records/lex/mocking.md): The ability to substitute test doubles for real dependencies by injecting them.
- [Runtime Lookup](https://banes-lab.com/records/lex/runtime-lookup.md): The ability to look up a needed service by name at runtime.
- [Third-Party Extension](https://banes-lab.com/records/lex/third-party-extension.md): The ability for outside developers to extend the system through published extension points.
- [Registry](https://banes-lab.com/records/lex/registry.md): A central store that maps keys to registered components for later lookup.
- [Externalized Flag State](https://banes-lab.com/records/lex/externalized-flag-state.md): The requirement that feature-flag values live in external configuration, not hardcoded in the code.
- [Keyed Registration](https://banes-lab.com/records/lex/keyed-registration.md): The requirement that each component register under a unique key by which it can be retrieved.
- [Registration Protocol](https://banes-lab.com/records/lex/registration-protocol.md): The requirement of a defined protocol by which services register and deregister themselves.
- [API Surface Growth](https://banes-lab.com/records/lex/api-surface-growth.md): The degree to which adding extension points enlarges the public API that must be kept stable.
- [Constructor Complexity](https://banes-lab.com/records/lex/constructor-complexity.md): The degree to which injecting many dependencies through constructors makes them long and unwieldy.
- [Explicit Dependencies](https://banes-lab.com/records/lex/explicit-dependencies.md): The degree to which a component's dependencies are visible in its signature rather than acquired through hidden lookups.
- [Flag Debt](https://banes-lab.com/records/lex/flag-debt.md): The degree to which stale, unremoved feature flags accumulate and clutter the code over time.
- [Global State](https://banes-lab.com/records/lex/global-state.md): The degree to which a global registry behaves as shared global state that any code can reach.
- [Registry Availability](https://banes-lab.com/records/lex/registry-availability.md): The degree to which the whole system's operation depends on the service registry staying available.
- [Platform Migration](https://banes-lab.com/records/lex/platform-migration.md): The ability to move a system to a different platform with little or no rework.
- [Platform Optimization](https://banes-lab.com/records/lex/platform-optimization.md): The degree to which staying portable across platforms forgoes optimizations specific to any one of them.
- [Platform-Specific Coupling](https://banes-lab.com/records/lex/platform-specific-coupling.md): Binding code to one platform's APIs and assumptions, so it cannot run elsewhere without rewriting.
- [Cross-Platform Deployment](https://banes-lab.com/records/lex/cross-platform-deployment.md): The ability to deploy the same software unchanged across different operating systems and platforms.
- [Native Optimization](https://banes-lab.com/records/lex/native-optimization.md): The degree to which staying platform-independent forgoes optimizations native to a specific platform.
- [OS/Vendor Lock-In](https://banes-lab.com/records/lex/os-vendor-lock-in.md): Depending on one operating system or vendor's proprietary features, so switching away becomes costly or impossible.
- [Platform Abstraction](https://banes-lab.com/records/lex/platform-abstraction.md): The requirement that platform-specific details sit behind an abstraction the rest of the system depends on.
- [Reliable Deployment](https://banes-lab.com/records/lex/reliable-deployment.md): The ability to deploy with confidence because every environment behaves the same way.
- [Snowflake Environments](https://banes-lab.com/records/lex/snowflake-environments.md): Environments each configured by hand into unique, unreproducible states, so what works in one fails in another.
- [Externalized Config](https://banes-lab.com/records/lex/externalized-config.md): The requirement that configuration live outside the container image so one image runs in any environment.
- [Host-Coupled Deployment](https://banes-lab.com/records/lex/host-coupled-deployment.md): Deploying software that depends on specifics of its host machine, so it cannot be moved or reproduced elsewhere.
- [Image Complexity](https://banes-lab.com/records/lex/image-complexity.md): The degree to which packaging everything into a container image grows the image and its maintenance burden.
- [Image Definition](https://banes-lab.com/records/lex/image-definition.md): A declarative file specifying how a container image is built from a base and its dependencies.
- [Repeatable Runtime Packaging](https://banes-lab.com/records/lex/repeatable-runtime-packaging.md): The ability to package an application and its runtime into one reproducible, portable unit.
- [Automated Provisioning](https://banes-lab.com/records/lex/automated-provisioning.md): The ability to create and configure infrastructure automatically from declarative definitions.
- [Manual Infrastructure Changes](https://banes-lab.com/records/lex/manual-infrastructure-changes.md): Changing infrastructure by hand instead of through code, so its state is undocumented and unreproducible.
- [Version Control](https://banes-lab.com/records/lex/version-control.md): A system that records changes to files over time so any version can be recovered, compared, or audited.
- [Applicable Standard](https://banes-lab.com/records/lex/applicable-standard.md): The requirement that the relevant external standard a system must meet be identified and adhered to.
- [Certification/Compatibility](https://banes-lab.com/records/lex/certification-compatibility.md): The ability to certify a system and interoperate with others by conforming to a shared standard.
- [Innovation/Flexibility](https://banes-lab.com/records/lex/innovation-flexibility.md): The degree to which conforming to an external standard limits the freedom to innovate beyond it.
- [Proprietary Deviation](https://banes-lab.com/records/lex/proprietary-deviation.md): Deviating from a shared standard with proprietary extensions, breaking interoperability with conformant systems.
- [Adapter/Port Abstraction](https://banes-lab.com/records/lex/adapter-port-abstraction.md): A boundary abstraction separating core logic from external protocols via port interfaces and pluggable adapters.
- [Protocol Swap](https://banes-lab.com/records/lex/protocol-swap.md): The ability to switch the transport or wire protocol without changing core domain logic.
- [Protocol-Coupled Domain Logic](https://banes-lab.com/records/lex/protocol-coupled-domain-logic.md): Domain logic written directly against a specific protocol, so changing the protocol means rewriting the core.
- [Protocol-Specific Features](https://banes-lab.com/records/lex/protocol-specific-features.md): The degree to which staying protocol-independent forgoes features unique to any one protocol.
- [Config Schema](https://banes-lab.com/records/lex/config-schema.md): A schema defining the structure, types, and defaults of a system's externalized configuration.
- [Config Sprawl](https://banes-lab.com/records/lex/config-sprawl.md): The degree to which externalizing configuration across many sources scatters it and makes it hard to track.
- [Environment-Specific Deployment](https://banes-lab.com/records/lex/environment-specific-deployment.md): The ability to deploy one build into different environments by supplying environment-specific configuration.
- [Secure Config Handling](https://banes-lab.com/records/lex/secure-config-handling.md): The requirement that secrets and sensitive configuration be stored and injected securely, never hardcoded.
- [Deploy Time](https://banes-lab.com/records/lex/deploy-time.md): The degree to which replacing whole instances rather than patching them in place lengthens deployment time.
- [Deterministic Redeploys](https://banes-lab.com/records/lex/deterministic-redeploys.md): The ability to redeploy identical infrastructure every time by replacing instances from a fixed definition.
- [In-Place Server Mutation](https://banes-lab.com/records/lex/in-place-server-mutation.md): Modifying running servers in place over time, so their state drifts and can no longer be reproduced.
- [Instance Replacement over Mutation](https://banes-lab.com/records/lex/instance-replacement-over-mutation.md): The ability to update infrastructure by replacing instances wholesale rather than mutating them in place.
- [Availability](https://banes-lab.com/records/lex/availability.md): The proportion of time a system is operational and able to serve requests.
- [Security](https://banes-lab.com/records/lex/security.md): The degree to which a system protects its data and behavior from unauthorized access, misuse, or attack.
- [Simplicity](https://banes-lab.com/records/lex/simplicity.md): The absence of unnecessary structure, keeping a system easy to understand and change.
- [Debuggability](https://banes-lab.com/records/lex/debuggability.md): The ease with which a fault can be located and understood from a system's observable behavior.
- [Maintainability](https://banes-lab.com/records/lex/maintainability.md): The ease with which a system can be corrected, adapted, and extended over its lifetime.
- [Complexity](https://banes-lab.com/records/lex/complexity.md): The degree of interdependence and intricacy that makes a system harder to reason about and change.
- [Fault Isolation](https://banes-lab.com/records/lex/fault-isolation.md): The degree to which a failure in one component is contained and prevented from cascading to others.
- [Architecture Compliance](https://banes-lab.com/records/lex/architecture-compliance.md): The degree to which an implementation conforms to its intended architectural rules, boundaries, and constraints.
- [Coordination Overhead](https://banes-lab.com/records/lex/coordination-overhead.md): The additional cost incurred to synchronize and coordinate concurrent or distributed units of work.
- [Data Integrity](https://banes-lab.com/records/lex/data-integrity.md): The accuracy, consistency, and validity of data maintained over its entire lifecycle.
- [Discoverability](https://banes-lab.com/records/lex/discoverability.md): The ease with which a system's components, capabilities, or endpoints can be found and understood.
- [Mapping Overhead](https://banes-lab.com/records/lex/mapping-overhead.md): The additional cost of translating data or calls between two differing representations or models.
- [Operational Overhead](https://banes-lab.com/records/lex/operational-overhead.md): The ongoing effort and resource cost of deploying, running, and maintaining a system in production.
- [Ordering](https://banes-lab.com/records/lex/ordering.md): The guarantee that events or messages are processed in a well-defined, consistent sequence.
- [Partial Availability](https://banes-lab.com/records/lex/partial-availability.md): The condition in which a system continues serving a subset of its functions while some components are unavailable.
- [Performance](https://banes-lab.com/records/lex/performance.md): The speed, throughput, and resource efficiency with which a system performs its work.
- [Policy Complexity](https://banes-lab.com/records/lex/policy-complexity.md): The difficulty of understanding, maintaining, and reasoning about a policy as its rules multiply.
- [Readability](https://banes-lab.com/records/lex/readability.md): The ease with which source code can be read and understood by a developer.
- [Reliability](https://banes-lab.com/records/lex/reliability.md): The degree to which a system performs its required functions correctly and consistently over time.
- [Resource Efficiency](https://banes-lab.com/records/lex/resource-efficiency.md): The degree to which a system accomplishes its work using minimal computational resources.
- [Retry Safety](https://banes-lab.com/records/lex/retry-safety.md): The property that an operation can be retried without producing duplicate or inconsistent effects.
- [Robustness](https://banes-lab.com/records/lex/robustness.md): The degree to which a system continues to operate correctly under invalid input, stress, or unexpected conditions.
- [Static Safety](https://banes-lab.com/records/lex/static-safety.md): The guarantee that whole classes of errors are caught at compile time, before code runs.
- [Substitutability](https://banes-lab.com/records/lex/substitutability.md): The degree to which a component can be replaced by another honoring the same contract without breaking clients.
- [Team Autonomy](https://banes-lab.com/records/lex/team-autonomy.md): The degree to which a team can make and deliver decisions independently, without cross-team coordination.
- [Tooling Complexity](https://banes-lab.com/records/lex/tooling-complexity.md): The effort required to set up, learn, and maintain the tools a technique or approach depends on.
- [User Experience](https://banes-lab.com/records/lex/user-experience.md): The overall quality of a user's interaction with a system, including responsiveness, clarity, and ease of use.
- [Closed Static Core](https://banes-lab.com/records/lex/closed-static-core.md): A core fixed at build time that cannot accept new capabilities without being recompiled.
- [Compile-Time Binding](https://banes-lab.com/records/lex/compile-time-binding.md): Binding a call to a specific implementation at compile time, so the target cannot vary at runtime.
- [Early Binding](https://banes-lab.com/records/lex/early-binding.md): Fixing which implementation a call uses at compile time, preventing a runtime choice.
- [Hardcoded Endpoints](https://banes-lab.com/records/lex/hardcoded-endpoints.md): Hardcoding service network addresses instead of discovering them dynamically.
- [Manual Registration](https://banes-lab.com/records/lex/manual-registration.md): Requiring each component to be registered by hand instead of being discovered automatically.
- [Static Linking](https://banes-lab.com/records/lex/static-linking.md): Binding all components at build time through static linking, so nothing can be discovered at runtime.
- [Static Wiring](https://banes-lab.com/records/lex/static-wiring.md): Wiring components together at build time, so composition cannot vary at runtime.
- [Capability Addition without Core Modification](https://banes-lab.com/records/lex/capability-addition-without-core-modification.md): The ability to add new capabilities at runtime without modifying the core.
- [Deferred Implementation Choice](https://banes-lab.com/records/lex/deferred-implementation-choice.md): The ability to postpone choosing a concrete implementation until runtime.
- [Dynamic Routing](https://banes-lab.com/records/lex/dynamic-routing.md): The ability to route requests to service instances discovered at runtime.
- [Environment-Specific Composition](https://banes-lab.com/records/lex/environment-specific-composition.md): The ability to assemble different implementations per environment at runtime.
- [Self-Registration](https://banes-lab.com/records/lex/self-registration.md): The ability for a component to register itself on load without external wiring.
- [Registry/Discovery Mechanism](https://banes-lab.com/records/lex/registry-discovery-mechanism.md): A facility that lets components find and resolve one another at runtime.
- [Replace Conditional with Polymorphism](https://banes-lab.com/records/lex/replace-conditional-with-polymorphism.md): Replacing a branching conditional on type with polymorphic dispatch through a shared interface.
- [Conventions](https://banes-lab.com/records/lex/conventions.md): The requirement that components follow shared naming or placement conventions so they can be found automatically.
- [Runtime Discovery or Configuration](https://banes-lab.com/records/lex/runtime-discovery-or-configuration.md): The requirement that implementations be discoverable or configurable at runtime rather than fixed.
- [Runtime Resolution](https://banes-lab.com/records/lex/runtime-resolution.md): The requirement that a symbol's concrete binding be resolved during execution rather than at compile time.
- [Extensibility](https://banes-lab.com/records/lex/extensibility.md): The degree to which new behavior can be added with minimal change to existing code.
- [Startup Cost](https://banes-lab.com/records/lex/startup-cost.md): The degree to which scanning for components at startup slows the system's initialization.
- [Anecdotal Performance Claims](https://banes-lab.com/records/lex/anecdotal-performance-claims.md): Asserting performance characteristics from anecdote or intuition rather than measured evidence.
- [Anecdotal Timing](https://banes-lab.com/records/lex/anecdotal-timing.md): Judging how fast code runs from casual observation instead of controlled measurement.
- [Bottlenecks](https://banes-lab.com/records/lex/bottlenecks.md): A single stage that constrains overall throughput because all work must pass through it.
- [Fixed Provisioning](https://banes-lab.com/records/lex/fixed-provisioning.md): Allocating a static amount of capacity regardless of demand, so the system is either starved or wasteful.
- [Fixed-Capacity Design](https://banes-lab.com/records/lex/fixed-capacity-design.md): Building a system around a fixed capacity ceiling that cannot grow when load increases.
- [Full Materialization](https://banes-lab.com/records/lex/full-materialization.md): Loading an entire dataset into memory at once when streaming or chunking would suffice, risking exhaustion.
- [Global Shared State](https://banes-lab.com/records/lex/global-shared-state.md): A single mutable state shared across all workers, forcing coordination and preventing independent scaling.
- [Guess-Based Capacity](https://banes-lab.com/records/lex/guess-based-capacity.md): Sizing capacity from guesswork rather than a model of arrival and service rates.
- [Guess-Based Optimization](https://banes-lab.com/records/lex/guess-based-optimization.md): Optimizing based on assumptions about where time is spent rather than profiling evidence.
- [Guesswork](https://banes-lab.com/records/lex/guesswork.md): Deciding where to optimize by intuition instead of measured profiling data.
- [Hard Resource Ceiling](https://banes-lab.com/records/lex/hard-resource-ceiling.md): A fixed upper bound on a single machine's resources that caps how far vertical scaling can go.
- [Inefficient Algorithm Choice](https://banes-lab.com/records/lex/inefficient-algorithm-choice.md): Selecting an algorithm whose complexity scales poorly for the expected input size.
- [Instance Affinity](https://banes-lab.com/records/lex/instance-affinity.md): Binding a client to a specific server instance for its state, preventing free rebalancing across instances.
- [Instance-Local State](https://banes-lab.com/records/lex/instance-local-state.md): Holding request-spanning state on one instance, so requests cannot be served by any other instance.
- [Local Micro-Optimization](https://banes-lab.com/records/lex/local-micro-optimization.md): Tuning a non-bottleneck section for marginal gains while the constraint that limits performance goes unaddressed.
- [Long Blocking Work](https://banes-lab.com/records/lex/long-blocking-work.md): Performing lengthy synchronous work on a request path, blocking it and inflating latency.
- [Origin-Only Serving](https://banes-lab.com/records/lex/origin-only-serving.md): Serving all content directly from the origin with no edge caching, concentrating load and adding distance latency.
- [Premature Optimization](https://banes-lab.com/records/lex/premature-optimization.md): Optimizing code before evidence shows it matters, adding complexity for gains that may never be needed.
- [Resource Waste/Saturation](https://banes-lab.com/records/lex/resource-waste-saturation.md): Running resources far below or far above healthy utilization, either wasting capacity or saturating it.
- [Sequential Bottleneck](https://banes-lab.com/records/lex/sequential-bottleneck.md): A portion of work that must run serially, capping the speedup that parallelism can achieve.
- [Single Monolithic Store](https://banes-lab.com/records/lex/single-monolithic-store.md): Concentrating all data in one store that cannot be partitioned, capping write and storage scalability.
- [Single Target Routing](https://banes-lab.com/records/lex/single-target-routing.md): Directing all traffic to one target instead of distributing it, wasting capacity and creating a bottleneck.
- [Single-Primary Read Contention](https://banes-lab.com/records/lex/single-primary-read-contention.md): Serving all reads from the single primary, so read load contends with writes and limits throughput.
- [Unbounded Access](https://banes-lab.com/records/lex/unbounded-access.md): Permitting callers to make unlimited requests with no rate limit, allowing overload and abuse.
- [Unbounded Memory Growth](https://banes-lab.com/records/lex/unbounded-memory-growth.md): Accumulating state without bound so memory usage grows until the process exhausts it.
- [Unbounded Runtime Growth](https://banes-lab.com/records/lex/unbounded-runtime-growth.md): An algorithm whose running time grows without bound as input scales, becoming infeasible at size.
- [Arrival and Service Rates](https://banes-lab.com/records/lex/arrival-and-service-rates.md): The measured rates at which requests arrive and at which a server completes them, the inputs a queuing model needs.
- [Bottleneck Awareness](https://banes-lab.com/records/lex/bottleneck-awareness.md): The ability to recognize which component limits a system's overall throughput.
- [Bottleneck Evidence](https://banes-lab.com/records/lex/bottleneck-evidence.md): Measured data identifying which component constrains performance, justifying where to optimize.
- [Cacheable Content](https://banes-lab.com/records/lex/cacheable-content.md): The requirement that content be stable enough to serve from a cache without harmful staleness.
- [Capacity Model](https://banes-lab.com/records/lex/capacity-model.md): A representation of how a system's capacity responds to load, used to predict its limits.
- [Complexity Awareness](https://banes-lab.com/records/lex/complexity-awareness.md): The ability to reason about how an algorithm's cost grows with input size.
- [Complexity Model](https://banes-lab.com/records/lex/complexity-model.md): A representation of how an algorithm's resource use scales with input size.
- [Externalized State](https://banes-lab.com/records/lex/externalized-state.md): The requirement that session or request state be held outside the serving instance, in a shared store.
- [Input Size Model](https://banes-lab.com/records/lex/input-size-model.md): A representation of the input dimension against which an algorithm's running time is measured.
- [Invalidation Policy](https://banes-lab.com/records/lex/invalidation-policy.md): The rules determining when cached entries are considered stale and must be refreshed or evicted.
- [Load Model](https://banes-lab.com/records/lex/load-model.md): A representation of the expected volume and pattern of demand a system must handle.
- [Memory Model](https://banes-lab.com/records/lex/memory-model.md): A representation of how an algorithm's memory use grows with input size.
- [Multiple Targets](https://banes-lab.com/records/lex/multiple-targets.md): The precondition that more than one interchangeable backend exists across which traffic can be spread.
- [Partition Key](https://banes-lab.com/records/lex/partition-key.md): The field whose value determines which shard or partition a record belongs to.
- [Partition Strategy](https://banes-lab.com/records/lex/partition-strategy.md): A scheme for dividing data or work across independent partitions to distribute load and enable parallelism.
- [Quota Policy](https://banes-lab.com/records/lex/quota-policy.md): The declared limits on how many requests a caller may make within a time window.
- [Repeatable Test Environment](https://banes-lab.com/records/lex/repeatable-test-environment.md): A controlled, reproducible environment in which measurements can be compared meaningfully across runs.
- [Representative Workload](https://banes-lab.com/records/lex/representative-workload.md): A workload that reflects production usage closely enough that measurements generalize.
- [Resource Headroom](https://banes-lab.com/records/lex/resource-headroom.md): The degree of spare capacity remaining on a machine before its resource ceiling is reached.
- [Space Complexity Awareness](https://banes-lab.com/records/lex/space-complexity-awareness.md): The ability to reason about how an algorithm's memory use grows with input size.
- [Statelessness or Shared State Strategy](https://banes-lab.com/records/lex/statelessness-or-shared-state-strategy.md): A decision to make instances stateless or externalize state to a shared store, so any instance can serve any request.
- [Abuse/Overload Protection](https://banes-lab.com/records/lex/abuse-overload-protection.md): The ability to shield a system from abusive or excessive request volume.
- [Bottleneck Detection](https://banes-lab.com/records/lex/bottleneck-detection.md): The ability to locate the component that most constrains overall performance.
- [Capacity Increase without Distribution](https://banes-lab.com/records/lex/capacity-increase-without-distribution.md): The ability to raise capacity by enlarging a single machine rather than adding more machines.
- [Comparative Analysis](https://banes-lab.com/records/lex/comparative-analysis.md): The ability to compare algorithms by how their cost grows, independent of hardware.
- [Cost Efficiency](https://banes-lab.com/records/lex/cost-efficiency.md): The degree to which a system delivers its work at the lowest resource cost.
- [Dynamic Capacity](https://banes-lab.com/records/lex/dynamic-capacity.md): The ability to add or remove capacity automatically as demand rises and falls.
- [Efficient Processing](https://banes-lab.com/records/lex/efficient-processing.md): The ability to complete work using the fewest operations and least resource for the input.
- [Evidence-Based Optimization](https://banes-lab.com/records/lex/evidence-based-optimization.md): The activity of improving performance guided by measurement rather than assumption.
- [Geographically-Local Delivery](https://banes-lab.com/records/lex/geographically-local-delivery.md): The ability to serve content from a location near the user, cutting distance latency.
- [Growth Handling](https://banes-lab.com/records/lex/growth-handling.md): The ability to absorb increasing load without redesign.
- [Large Dataset Scaling](https://banes-lab.com/records/lex/large-dataset-scaling.md): The ability to grow storage and throughput by spreading a dataset across many shards.
- [Latency Reduction](https://banes-lab.com/records/lex/latency-reduction.md): The ability to lower response time by serving results from a nearer or faster source.
- [Load Handling](https://banes-lab.com/records/lex/load-handling.md): The ability to process a high volume of work without degrading.
- [Memory Scalability](https://banes-lab.com/records/lex/memory-scalability.md): The ability to handle larger inputs without memory use growing prohibitively.
- [Multi-Core Utilization](https://banes-lab.com/records/lex/multi-core-utilization.md): The ability to use multiple processor cores simultaneously for a single workload.
- [Origin Offload](https://banes-lab.com/records/lex/origin-offload.md): The ability to relieve the origin server by serving cached copies from the edge.
- [Overlapping Work](https://banes-lab.com/records/lex/overlapping-work.md): The ability to make progress on multiple tasks over the same period by interleaving them.
- [Read Traffic Offload](https://banes-lab.com/records/lex/read-traffic-offload.md): The ability to divert read queries to replicas, relieving the primary.
- [Reduced Load](https://banes-lab.com/records/lex/reduced-load.md): The ability to lessen work reaching a backend by serving repeat results from a cache.
- [Regression Detection](https://banes-lab.com/records/lex/regression-detection.md): The ability to catch a performance regression by comparing measurements against a baseline.
- [Responsiveness](https://banes-lab.com/records/lex/responsiveness.md): The degree to which a system reacts quickly to user actions or requests.
- [Scalability Analysis](https://banes-lab.com/records/lex/scalability-analysis.md): The activity of assessing how a system's cost grows as load or input increases.
- [Scale-Out](https://banes-lab.com/records/lex/scale-out.md): The ability to add capacity by adding more machines that share the load.
- [Targeted Improvement](https://banes-lab.com/records/lex/targeted-improvement.md): The ability to direct optimization effort at the specific constraint that limits performance.
- [Traffic Distribution](https://banes-lab.com/records/lex/traffic-distribution.md): The ability to spread incoming requests across multiple backends evenly.
- [Utilization-Based Sizing](https://banes-lab.com/records/lex/utilization-based-sizing.md): The ability to size capacity from measured utilization and wait-time targets.
- [Wait-Time Prediction](https://banes-lab.com/records/lex/wait-time-prediction.md): The ability to predict how long work will wait given arrival and service rates.
- [Always-Fresh Reads](https://banes-lab.com/records/lex/always-fresh-reads.md): The degree to which every read returns the most recent write, which caching trades away for speed.
- [Cache Invalidation](https://banes-lab.com/records/lex/cache-invalidation.md): The activity of removing or refreshing cached entries so stale data is not served.
- [Constant-Factor Practicality](https://banes-lab.com/records/lex/constant-factor-practicality.md): The degree to which constant factors, ignored by asymptotic analysis, affect measured performance.
- [Cost/Limit](https://banes-lab.com/records/lex/cost-limit.md): The degree to which a bigger single machine costs disproportionately more and eventually hits a hard limit.
- [CPU Cost](https://banes-lab.com/records/lex/cpu-cost.md): The degree of processor time a technique consumes, often traded against memory savings.
- [Cross-Shard Queries](https://banes-lab.com/records/lex/cross-shard-queries.md): The degree of difficulty and cost of a query that must gather data from multiple shards.
- [Distributed Complexity](https://banes-lab.com/records/lex/distributed-complexity.md): The degree of intricacy introduced by spreading work across distributed nodes.
- [Distributed Coordination](https://banes-lab.com/records/lex/distributed-coordination.md): The degree of coordination overhead required to keep distributed instances consistent.
- [Environment Drift](https://banes-lab.com/records/lex/environment-drift.md): The degree to which a test or runtime environment diverges from a reference over time, undermining comparability.
- [Implementation Simplicity](https://banes-lab.com/records/lex/implementation-simplicity.md): The degree to which code stays simple and clear, sometimes traded against maximal efficiency.
- [Measurement Overhead](https://banes-lab.com/records/lex/measurement-overhead.md): The degree of performance cost that the act of measuring imposes on the system being measured.
- [Model Assumptions](https://banes-lab.com/records/lex/model-assumptions.md): The simplifying premises a performance model depends on, which limit how well it matches reality.
- [Over-Provisioning](https://banes-lab.com/records/lex/over-provisioning.md): The degree to which allocated capacity exceeds demand, trading waste for safety margin.
- [Read-Your-Writes Consistency](https://banes-lab.com/records/lex/read-your-writes-consistency.md): The degree to which a client is guaranteed to see its own prior writes, which replica lag can break.
- [Readability/Maintainability](https://banes-lab.com/records/lex/readability-maintainability.md): The degree to which code stays readable and maintainable, sometimes sacrificed for performance.
- [Rebalancing Complexity](https://banes-lab.com/records/lex/rebalancing-complexity.md): The degree of difficulty of redistributing data when partitions are added or removed.
- [Session Affinity](https://banes-lab.com/records/lex/session-affinity.md): Routing all of a client's requests to the same server instance so its session state stays local.
- [State Access Latency](https://banes-lab.com/records/lex/state-access-latency.md): The degree of added latency incurred when state is fetched from an external store rather than held locally.
- [Throughput/Batching](https://banes-lab.com/records/lex/throughput-batching.md): The degree to which batching work raises throughput at the cost of per-item latency.
- [Warm-Up Latency](https://banes-lab.com/records/lex/warm-up-latency.md): The degree of delay before newly-added capacity becomes ready to serve traffic.
- [Flexible Input](https://banes-lab.com/records/lex/flexible-input.md): The degree to which strictly validating every payload rejects the loosely-shaped input a caller might legitimately send.
- [Untyped Payloads](https://banes-lab.com/records/lex/untyped-payloads.md): Accepting data at a boundary with no schema, so malformed or unexpected shapes flow in unchecked.
- [Dynamic Untyped Boundaries](https://banes-lab.com/records/lex/dynamic-untyped-boundaries.md): Passing untyped values across module or service boundaries, so type errors surface only at runtime.
- [Explicit Types](https://banes-lab.com/records/lex/explicit-types.md): The requirement that values crossing a boundary carry explicit, declared types rather than open-ended ones.
- [Rapid Scripting](https://banes-lab.com/records/lex/rapid-scripting.md): The degree to which requiring explicit types slows the quick, exploratory coding that dynamic typing allows.
- [Bounded Context Autonomy](https://banes-lab.com/records/lex/bounded-context-autonomy.md): The degree to which enforcing one canonical model limits each bounded context's freedom to model its own domain.
- [Multiple Competing Models](https://banes-lab.com/records/lex/multiple-competing-models.md): Several inconsistent models of the same concept coexisting, so translations between them drift and conflict.
- [Normalized Translation](https://banes-lab.com/records/lex/normalized-translation.md): The ability to translate between systems through one shared canonical form rather than many pairwise mappings.
- [Bounded Context Purity](https://banes-lab.com/records/lex/bounded-context-purity.md): The degree to which sharing one enterprise data model erodes the conceptual purity of each bounded context.
- [Cross-System Mapping](https://banes-lab.com/records/lex/cross-system-mapping.md): The ability to map data between systems through a single shared canonical representation.
- [Local Model Autonomy](https://banes-lab.com/records/lex/local-model-autonomy.md): The degree to which a bounded context is free to define and evolve its own data model independently of a shared canonical one.
- [Service-Specific Schemas](https://banes-lab.com/records/lex/service-specific-schemas.md): The degree to which a shared canonical schema competes with each service's need for its own tailored schema.
- [Ambiguous Encoding](https://banes-lab.com/records/lex/ambiguous-encoding.md): Representing the same value in multiple encodings without normalizing, so equal values compare as different.
- [Canonical Format](https://banes-lab.com/records/lex/canonical-format.md): The requirement that a single normalized form be defined for values before they are compared or stored.
- [Deduplication](https://banes-lab.com/records/lex/deduplication.md): The ability to recognize and collapse values that are equivalent once reduced to canonical form.
- [Lossless Preservation](https://banes-lab.com/records/lex/lossless-preservation.md): The degree to which reducing values to a canonical form can discard distinctions the original preserved.
- [Security Checks](https://banes-lab.com/records/lex/security-checks.md): The ability to apply security checks reliably by first reducing input to one unambiguous form.
- [Canonical Definition](https://banes-lab.com/records/lex/canonical-definition.md): The requirement that each fact have one authoritative definition that all consumers reference.
- [Duplicated Authority](https://banes-lab.com/records/lex/duplicated-authority.md): Two or more places each claiming to own the same fact, so they drift and disagree over time.
- [Data Semantics](https://banes-lab.com/records/lex/data-semantics.md): The requirement that the meaning and dependencies of data be understood before it is decomposed into relations.
- [Denormalized Read Models](https://banes-lab.com/records/lex/denormalized-read-models.md): A read-optimized model that deliberately duplicates data to serve queries fast, trading storage and write cost for read speed.
- [Non-Redundant Storage](https://banes-lab.com/records/lex/non-redundant-storage.md): The ability to store each fact once, so it cannot drift out of sync with copies.
- [Query Performance](https://banes-lab.com/records/lex/query-performance.md): The degree to which splitting data across normalized relations forces costly joins on read.
- [Reduced Redundancy](https://banes-lab.com/records/lex/reduced-redundancy.md): The ability to eliminate duplicated facts by referencing a single stored copy.
- [Disambiguation](https://banes-lab.com/records/lex/disambiguation.md): The ability to give each concept one unambiguous name and meaning across a domain.
- [Polysemy Across Contexts](https://banes-lab.com/records/lex/polysemy-across-contexts.md): The degree to which one term legitimately carries different meanings in different bounded contexts.
- [Cross-Context Terminology](https://banes-lab.com/records/lex/cross-context-terminology.md): The degree to which agreeing on shared terms strains against the distinct vocabularies different contexts need.
- [Domain Collaboration](https://banes-lab.com/records/lex/domain-collaboration.md): The requirement that domain experts and developers collaborate to agree on shared terminology.
- [Technical/Domain Mismatch](https://banes-lab.com/records/lex/technical-domain-mismatch.md): Naming code in technical terms disconnected from the domain, so experts and developers talk past each other.
- [Ambiguous API](https://banes-lab.com/records/lex/ambiguous-api.md): An interface whose names and parameters hide what it does, so callers must guess or read the implementation.
- [Clear Semantics](https://banes-lab.com/records/lex/clear-semantics.md): The requirement that an interface's names convey what each operation does and expects.
- [Concise Naming](https://banes-lab.com/records/lex/concise-naming.md): The degree to which naming an interface fully for clarity works against keeping names short.
- [Correct Usage](https://banes-lab.com/records/lex/correct-usage.md): The ability of callers to use an interface correctly because its names reveal its intent.
- [Naming Consistency](https://banes-lab.com/records/lex/naming-consistency.md): The requirement that names for the same concept be used consistently across an interface.
- [Clever Abstractions](https://banes-lab.com/records/lex/clever-abstractions.md): The degree to which clever, non-obvious abstractions trade familiarity for surprise to the reader.
- [Convention](https://banes-lab.com/records/lex/convention.md): The requirement that a design follow established conventions so its behavior matches expectations.
- [Safe Use](https://banes-lab.com/records/lex/safe-use.md): The ability to use an interface safely because it behaves the way its name and shape suggest.
- [Duplicated Denormalized Columns](https://banes-lab.com/records/lex/duplicated-denormalized-columns.md): The same fact copied into many columns and rows, so updates must touch every copy or leave them inconsistent.
- [Functional Dependencies](https://banes-lab.com/records/lex/functional-dependencies.md): The requirement that the dependencies determining which attributes fix others be identified before decomposing a schema.
- [Read Performance](https://banes-lab.com/records/lex/read-performance.md): The degree to which normalizing a schema into many relations forces joins that slow reads.
- [Update-Anomaly Elimination](https://banes-lab.com/records/lex/update-anomaly-elimination.md): The ability to eliminate update anomalies by storing each fact in exactly one place.
- [Ad-Hoc Permission Checks](https://banes-lab.com/records/lex/ad-hoc-permission-checks.md): Authorization logic scattered inline throughout the codebase instead of centralized, leaving checks inconsistent and easy to omit.
- [Ambient-Credential Trust](https://banes-lab.com/records/lex/ambient-credential-trust.md): Treating any request that carries ambient credentials, such as a session cookie, as legitimate without verifying its origin or intent.
- [Anonymous Sensitive Access](https://banes-lab.com/records/lex/anonymous-sensitive-access.md): Permitting access to sensitive resources without first establishing the caller's identity.
- [Assumption-Driven Security](https://banes-lab.com/records/lex/assumption-driven-security.md): Designing defenses around assumed threats rather than a deliberate analysis of realistic attack vectors.
- [Authenticated-Equals-Authorized](https://banes-lab.com/records/lex/authenticated-equals-authorized.md): Conflating authentication with authorization, so any authenticated caller is granted access without a permission check.
- [Broad Admin Access](https://banes-lab.com/records/lex/broad-admin-access.md): Granting sweeping administrative privileges by default instead of the least access each role requires.
- [Document-Only Policy](https://banes-lab.com/records/lex/document-only-policy.md): Expressing security policy only as prose documentation, so it cannot be enforced automatically and drifts from what the system does.
- [Hardcoded Rules](https://banes-lab.com/records/lex/hardcoded-rules.md): Embedding access rules directly in code, so changing policy requires a code change and cannot respond to runtime attributes.
- [Hardcoded Secrets](https://banes-lab.com/records/lex/hardcoded-secrets.md): Embedding credentials, keys, or tokens directly in source or configuration, exposing them to anyone who can read it.
- [Immortal Client-Trusted Session](https://banes-lab.com/records/lex/immortal-client-trusted-session.md): A session that never expires and is trusted from client-supplied state alone, so a captured token grants indefinite access.
- [Insecure Defaults](https://banes-lab.com/records/lex/insecure-defaults.md): Shipping default settings that favor convenience over safety, leaving a system exposed unless it is explicitly hardened.
- [Manual-Only Review](https://banes-lab.com/records/lex/manual-only-review.md): Relying solely on human review to catch policy violations, which neither scales nor reliably covers every case.
- [Plaintext Sensitive Storage](https://banes-lab.com/records/lex/plaintext-sensitive-storage.md): Storing sensitive data unencrypted at rest, exposing it to anyone who reaches the underlying storage.
- [Plaintext Transport](https://banes-lab.com/records/lex/plaintext-transport.md): Sending data over an unencrypted channel, exposing it to interception and tampering in transit.
- [Point-in-Time Audit Only](https://banes-lab.com/records/lex/point-in-time-audit-only.md): Verifying compliance only at isolated audit moments, leaving the intervals between checks unmonitored for drift.
- [Raw Output Rendering](https://banes-lab.com/records/lex/raw-output-rendering.md): Emitting untrusted data into output without encoding it for its context, enabling injection attacks such as cross-site scripting.
- [Security as Afterthought](https://banes-lab.com/records/lex/security-as-afterthought.md): Deferring security concerns until late in development, when vulnerabilities are costly and difficult to remediate.
- [Single Control Reliance](https://banes-lab.com/records/lex/single-control-reliance.md): Depending on one security control with no layered defenses, so a single bypass compromises the whole system.
- [String-Concatenated SQL](https://banes-lab.com/records/lex/string-concatenated-sql.md): Assembling SQL queries by concatenating untrusted input into strings, opening the system to SQL injection.
- [Trusted Internal Network Assumption](https://banes-lab.com/records/lex/trusted-internal-network-assumption.md): Assuming that traffic originating inside the network perimeter is inherently trustworthy, ignoring insider and lateral-movement threats.
- [Trusting External Input](https://banes-lab.com/records/lex/trusting-external-input.md): Accepting external input as well-formed and safe without validating it, exposing the system to malformed or malicious data.
- [Unbounded Autonomy](https://banes-lab.com/records/lex/unbounded-autonomy.md): Allowing an actor or component to act without governance limits, so unsafe or unauthorized actions go unchecked.
- [Unbounded Data Collection](https://banes-lab.com/records/lex/unbounded-data-collection.md): Gathering and retaining more personal data than a purpose requires, inflating privacy risk and regulatory exposure.
- [Uncontrolled Change](https://banes-lab.com/records/lex/uncontrolled-change.md): Permitting changes to a controlled system without review, approval, or record, undermining compliance and traceability.
- [Unknown/Unowned Risk](https://banes-lab.com/records/lex/unknown-unowned-risk.md): A risk that has been neither identified nor assigned to an owner, so it goes unmanaged until it materializes.
- [Unnecessary Public Surface](https://banes-lab.com/records/lex/unnecessary-public-surface.md): Exposing more endpoints, ports, or interfaces publicly than the function requires, enlarging the attack surface.
- [Unrestricted Access](https://banes-lab.com/records/lex/unrestricted-access.md): Permitting access to a resource with no controls, so any caller can invoke any operation.
- [Assets](https://banes-lab.com/records/lex/assets.md): The data, systems, and capabilities of value that a threat model enumerates as the things worth protecting.
- [Attribute Definitions](https://banes-lab.com/records/lex/attribute-definitions.md): Declared descriptions of the subject, resource, action, and environment attributes that an access policy evaluates.
- [Authenticated Principal](https://banes-lab.com/records/lex/authenticated-principal.md): The verified identity of the user or service on whose behalf a request executes, against which permissions are checked.
- [Authorization Policy](https://banes-lab.com/records/lex/authorization-policy.md): The declared set of rules determining which principals may perform which actions on which resources.
- [Consent/Policy](https://banes-lab.com/records/lex/consent-policy.md): The recorded permission and governing rules under which personal data may lawfully be collected and processed.
- [Context-Aware Encoding](https://banes-lab.com/records/lex/context-aware-encoding.md): Choosing an output encoding matched to the destination context, such as HTML, an attribute, a URL or a script, so data is neutralized wherever it lands.
- [Continuous Authorization](https://banes-lab.com/records/lex/continuous-authorization.md): The practice of re-verifying a caller's authorization on every request rather than trusting a single earlier check.
- [Controls](https://banes-lab.com/records/lex/controls.md): The safeguards and countermeasures put in place to reduce security or compliance risk to an acceptable level.
- [Data Minimization](https://banes-lab.com/records/lex/data-minimization.md): Collecting and retaining only the personal data strictly necessary for a stated purpose.
- [Defined Policy](https://banes-lab.com/records/lex/defined-policy.md): An explicit, declared set of rules specifying what is permitted or denied, against which enforcement acts.
- [Evidence Automation](https://banes-lab.com/records/lex/evidence-automation.md): The ability to generate and collect compliance evidence automatically from live systems rather than assembling it by hand.
- [Identity Proof](https://banes-lab.com/records/lex/identity-proof.md): The evidence a principal presents to establish its identity, such as a password, token, or certificate.
- [Key Management](https://banes-lab.com/records/lex/key-management.md): The activity of generating, distributing, rotating, and revoking cryptographic keys across their lifecycle.
- [Layered Controls](https://banes-lab.com/records/lex/layered-controls.md): The requirement that multiple independent safeguards protect a resource, so no single failure exposes it.
- [Machine-Readable Policies](https://banes-lab.com/records/lex/machine-readable-policies.md): Security or compliance policies expressed in a structured, executable format that tools can evaluate directly.
- [Minimal Exposure](https://banes-lab.com/records/lex/minimal-exposure.md): The condition of exposing only the endpoints, ports, and capabilities strictly required.
- [Minimal Permissions](https://banes-lab.com/records/lex/minimal-permissions.md): The requirement that each principal hold only the permissions its function needs.
- [Mitigation](https://banes-lab.com/records/lex/mitigation.md): The activity of reducing a risk's likelihood or impact through deliberate countermeasures.
- [Policy Engine](https://banes-lab.com/records/lex/policy-engine.md): A runtime component that evaluates access requests against declared policies and returns permit or deny decisions.
- [Query Parameter Binding](https://banes-lab.com/records/lex/query-parameter-binding.md): Passing query values as bound parameters separate from the query text, so input can never alter the query structure.
- [Request Origin Verification](https://banes-lab.com/records/lex/request-origin-verification.md): Confirming that a state-changing request originates from a trusted client, typically via a token or origin check.
- [Review](https://banes-lab.com/records/lex/review.md): The activity of examining a change or artifact against standards before it is accepted.
- [Risk Identification](https://banes-lab.com/records/lex/risk-identification.md): The activity of discovering and cataloguing the risks that could affect a system or objective.
- [Role Definitions](https://banes-lab.com/records/lex/role-definitions.md): Declared sets of permissions grouped into named roles that are assigned to principals.
- [Rotation Policy](https://banes-lab.com/records/lex/rotation-policy.md): The specified interval and procedure by which secrets or keys must be replaced to limit the value of any single compromise.
- [Secret Store](https://banes-lab.com/records/lex/secret-store.md): A dedicated, access-controlled repository that holds credentials and keys outside of application code.
- [Threat Scenarios](https://banes-lab.com/records/lex/threat-scenarios.md): Concrete descriptions of how an attacker might attempt to compromise a system, enumerated during threat modeling.
- [TLS/mTLS](https://banes-lab.com/records/lex/tls-mtls.md): Transport-layer protocols that encrypt a connection and, with mutual TLS, mutually authenticate both endpoints.
- [Trust Boundaries](https://banes-lab.com/records/lex/trust-boundaries.md): The demarcations in a system where the level of trust changes and data crossing them must be validated.
- [Strong Identity](https://banes-lab.com/records/lex/strong-identity.md): The requirement that every actor prove a strong, verified identity before any access is granted.
- [Validation Rules](https://banes-lab.com/records/lex/validation-rules.md): Declared constraints that input must satisfy, such as type, range, format and length, before it is accepted.
- [Automated Control](https://banes-lab.com/records/lex/automated-control.md): The ability to enforce rules automatically at runtime without manual intervention.
- [Bounded Session Lifetime](https://banes-lab.com/records/lex/bounded-session-lifetime.md): The degree to which a session's validity is time-limited so that access does not persist indefinitely.
- [Coarse-Grained Permission Management](https://banes-lab.com/records/lex/coarse-grained-permission-management.md): The ability to manage access by assigning broad, role-level permission sets rather than per-individual grants.
- [Compromise Containment](https://banes-lab.com/records/lex/compromise-containment.md): The ability to keep a breach confined to one layer or segment so it cannot spread system-wide.
- [Confidentiality](https://banes-lab.com/records/lex/confidentiality.md): The degree to which data is kept secret from all but authorized parties.
- [Confidentiality of Stored Data](https://banes-lab.com/records/lex/confidentiality-of-stored-data.md): The degree to which data held at rest remains unreadable to anyone without authorized access.
- [Context-Aware Authorization](https://banes-lab.com/records/lex/context-aware-authorization.md): The ability to base access decisions on the runtime context of a request, such as its attributes, its environment and the resource's state.
- [Control Selection](https://banes-lab.com/records/lex/control-selection.md): The activity of choosing which security controls to apply based on identified threats and their priority.
- [Data Protection](https://banes-lab.com/records/lex/data-protection.md): The ability to safeguard data against unauthorized access, loss, or disclosure throughout its lifecycle.
- [Fine-Grained Access Control](https://banes-lab.com/records/lex/fine-grained-access-control.md): The ability to grant or deny access at a precise level using specific attributes rather than broad roles.
- [Forged-Request Rejection](https://banes-lab.com/records/lex/forged-request-rejection.md): The ability to detect and reject requests that a user did not intentionally initiate.
- [Identity-Aware Authorization](https://banes-lab.com/records/lex/identity-aware-authorization.md): The ability to make access decisions grounded in a verified caller identity.
- [Injection Prevention](https://banes-lab.com/records/lex/injection-prevention.md): The ability to stop untrusted input from being interpreted as executable code or commands.
- [Injection-Safe Data Access](https://banes-lab.com/records/lex/injection-safe-data-access.md): The ability to query data such that input can never be interpreted as part of the query structure.
- [Integrity](https://banes-lab.com/records/lex/integrity.md): The degree to which data is protected from unauthorized or undetected alteration.
- [Ongoing Assurance](https://banes-lab.com/records/lex/ongoing-assurance.md): The ability to demonstrate continuously that controls remain effective, rather than only at audit time.
- [Perimeterless Security](https://banes-lab.com/records/lex/perimeterless-security.md): A security model that trusts no network location implicitly and verifies every request regardless of origin.
- [Priority-Based Controls](https://banes-lab.com/records/lex/priority-based-controls.md): The ability to apply controls in order of risk priority, addressing the greatest exposure first.
- [Privacy Compliance](https://banes-lab.com/records/lex/privacy-compliance.md): The degree to which a system meets the privacy obligations imposed by law and policy.
- [Proactive Risk Reduction](https://banes-lab.com/records/lex/proactive-risk-reduction.md): The ability to reduce risk by designing safeguards in from the start rather than patching flaws later.
- [Reduced Blast Radius](https://banes-lab.com/records/lex/reduced-blast-radius.md): The degree to which the impact of a compromise is confined to a limited scope.
- [Reduced Exploitability](https://banes-lab.com/records/lex/reduced-exploitability.md): The degree to which fewer exposed features leave a system harder to exploit.
- [Reduced Misconfiguration Risk](https://banes-lab.com/records/lex/reduced-misconfiguration-risk.md): The degree to which safe defaults lower the chance of an insecure configuration.
- [Regulatory Alignment](https://banes-lab.com/records/lex/regulatory-alignment.md): The degree to which a system conforms to the laws and regulations that govern it.
- [Resource Protection](https://banes-lab.com/records/lex/resource-protection.md): The ability to ensure that only permitted operations reach a protected resource.
- [Revocable Access](https://banes-lab.com/records/lex/revocable-access.md): The ability to withdraw a principal's access immediately when a session or grant is terminated.
- [Safe Credential Handling](https://banes-lab.com/records/lex/safe-credential-handling.md): The ability to store, transmit, and use credentials without exposing them.
- [Safe Rendering](https://banes-lab.com/records/lex/safe-rendering.md): The ability to display untrusted data without allowing it to execute as markup or script.
- [Secure Communication](https://banes-lab.com/records/lex/secure-communication.md): The ability to exchange data over a channel protected from interception and tampering.
- [Secure Configuration](https://banes-lab.com/records/lex/secure-configuration.md): The degree to which a system's settings and secrets are arranged to minimize exposure.
- [Zero Trust](https://banes-lab.com/records/lex/zero-trust.md): A security stance that grants no implicit trust and continuously verifies every access request regardless of its source.
- [Analytics/Personalization](https://banes-lab.com/records/lex/analytics-personalization.md): The ability to analyze collected data and tailor experiences to individuals, in tension with strict data minimization.
- [Certificate Management](https://banes-lab.com/records/lex/certificate-management.md): The activity of issuing, deploying, renewing, and revoking the digital certificates that transport encryption depends on.
- [Client Complexity](https://banes-lab.com/records/lex/client-complexity.md): The degree of additional effort a protective measure imposes on client implementations.
- [Developer Ergonomics](https://banes-lab.com/records/lex/developer-ergonomics.md): The degree to which a system is convenient and pleasant for developers to work with.
- [Dynamic Query Flexibility](https://banes-lab.com/records/lex/dynamic-query-flexibility.md): The degree of freedom to vary a query's structure at runtime, constrained when inputs must be bound as parameters.
- [Ease of Initial Use](https://banes-lab.com/records/lex/ease-of-initial-use.md): The degree to which a system is easy to start using without upfront configuration.
- [Feature Exposure](https://banes-lab.com/records/lex/feature-exposure.md): The degree to which functionality is made accessible, which broadens capability but enlarges the attack surface.
- [Formatting Flexibility](https://banes-lab.com/records/lex/formatting-flexibility.md): The degree of latitude to present output in varied formats, constrained when encoding must be strict.
- [Input Flexibility](https://banes-lab.com/records/lex/input-flexibility.md): The degree to which a system accepts varied or loosely-structured input, in tension with strict validation.
- [Key Operations](https://banes-lab.com/records/lex/key-operations.md): The degree of operational burden imposed by generating, rotating, and safeguarding cryptographic keys.
- [Latency/Complexity](https://banes-lab.com/records/lex/latency-complexity.md): The degree of added latency and complexity introduced by verifying every request rather than trusting a perimeter.
- [Operational Convenience](https://banes-lab.com/records/lex/operational-convenience.md): The degree to which broad access makes day-to-day operations easier, in tension with least privilege.
- [Pipeline Complexity](https://banes-lab.com/records/lex/pipeline-complexity.md): The degree of intricacy added to a delivery pipeline by embedding continuous checks within it.
- [Policy Maintenance](https://banes-lab.com/records/lex/policy-maintenance.md): The activity of keeping codified policies correct and current as requirements evolve.
- [Role Explosion](https://banes-lab.com/records/lex/role-explosion.md): The degree to which roles proliferate into many narrow definitions as access requirements grow.
- [Speed](https://banes-lab.com/records/lex/speed.md): The degree to which delivery proceeds rapidly, in tension with the caution that managing risk requires.
- [Team Velocity](https://banes-lab.com/records/lex/team-velocity.md): The rate at which a team delivers completed work, which governance overhead can slow.
- [Usability](https://banes-lab.com/records/lex/usability.md): The ease with which users can accomplish their goals with a system.
- [User Convenience](https://banes-lab.com/records/lex/user-convenience.md): The degree to which a system minimizes friction and effort for its users.
- [Automation Risk](https://banes-lab.com/records/lex/automation-risk.md): The degree to which automated self-healing may take incorrect corrective actions without human oversight.
- [Manual-Only Recovery](https://banes-lab.com/records/lex/manual-only-recovery.md): Depending entirely on human operators to detect and recover from every failure, so recovery is slow and unreliable.
- [False Recovery Actions](https://banes-lab.com/records/lex/false-recovery-actions.md): The degree to which acting on faulty signals leads automated recovery to take wrong or harmful corrective actions.
- [Health Signal](https://banes-lab.com/records/lex/health-signal.md): A machine-readable signal that reports whether a component is currently healthy.
- [Manual Intervention Dependency](https://banes-lab.com/records/lex/manual-intervention-dependency.md): Requiring a human to step in for recovery to proceed, so the system cannot heal on its own.
- [Reduced Mean Time to Recovery](https://banes-lab.com/records/lex/reduced-mean-time-to-recovery.md): The ability to shorten the mean time to recover from a failure by acting automatically.
- [Remediation Action](https://banes-lab.com/records/lex/remediation-action.md): A corrective action executed to return a system to a healthy state after a fault is detected.
- [Blind Routing](https://banes-lab.com/records/lex/blind-routing.md): Routing traffic to instances without checking their health, so requests hit dead or degraded nodes.
- [Observable Health Criteria](https://banes-lab.com/records/lex/observable-health-criteria.md): The requirement that explicit, observable criteria define when a component counts as healthy.
- [Readiness/Liveness Routing](https://banes-lab.com/records/lex/readiness-liveness-routing.md): The ability to route traffic only to instances that report themselves ready and alive.
- [Continuity During Failure](https://banes-lab.com/records/lex/continuity-during-failure.md): The ability to keep serving requests by switching to a standby when the primary fails.
- [Health Detection](https://banes-lab.com/records/lex/health-detection.md): The ability to detect that a component has failed so a switchover can be triggered.
- [Single Instance Dependency](https://banes-lab.com/records/lex/single-instance-dependency.md): Depending on a single instance with no standby, so its failure takes down the whole service.
- [Replication or Alternate Capacity](https://banes-lab.com/records/lex/replication-or-alternate-capacity.md): The requirement that duplicate copies or spare capacity exist to take over when a component fails.
- [Consistency Lag](https://banes-lab.com/records/lex/consistency-lag.md): The degree to which replicas trail the primary, so reads served from them may return stale data.
- [Consistency Policy](https://banes-lab.com/records/lex/consistency-policy.md): The requirement that a defined policy specify how and when replicas converge to a consistent state.
- [Read Scaling](https://banes-lab.com/records/lex/read-scaling.md): The ability to serve more read traffic by distributing it across replicas.
- [Single Copy State](https://banes-lab.com/records/lex/single-copy-state.md): Keeping only one copy of state, so its loss or unavailability takes down the whole system.
- [Cost/Cold Start](https://banes-lab.com/records/lex/cost-cold-start.md): The degree to which scaling capacity up and down incurs added cost and cold-start latency.
- [Demand-Based Capacity](https://banes-lab.com/records/lex/demand-based-capacity.md): The ability to match provisioned capacity to current demand automatically.
- [Fixed Capacity](https://banes-lab.com/records/lex/fixed-capacity.md): Provisioning a fixed, preset amount of capacity, rather than adapting it to demand.
- [Horizontal Scalability](https://banes-lab.com/records/lex/horizontal-scalability.md): The degree to which a system can grow by adding more interchangeable instances rather than enlarging one.
- [Detection Signal](https://banes-lab.com/records/lex/detection-signal.md): A machine-readable signal indicating that a fault or anomaly has been detected.
- [Incident Reduction](https://banes-lab.com/records/lex/incident-reduction.md): The ability to reduce the number of incidents that reach human responders by fixing them automatically.
- [Manual Remediation](https://banes-lab.com/records/lex/manual-remediation.md): Recovering from incidents through human-operated fixes, rather than automated remediation.
- [Remediation Workflow](https://banes-lab.com/records/lex/remediation-workflow.md): A defined sequence of steps carried out to remediate a detected incident.
- [Unsafe Automation](https://banes-lab.com/records/lex/unsafe-automation.md): The degree to which automating remediation risks taking harmful actions faster than a human can intervene.
- [Data Migration Compatibility](https://banes-lab.com/records/lex/data-migration-compatibility.md): The degree to which reverting code is constrained by forward data migrations that cannot easily be undone.
- [Fast Failure Recovery](https://banes-lab.com/records/lex/fast-failure-recovery.md): The ability to recover quickly from a bad release by reverting to the last good version.
- [Irreversible Deployment](https://banes-lab.com/records/lex/irreversible-deployment.md): Deploying in a way that cannot be undone, so a bad release cannot be rolled back.
- [Reversible Deployment](https://banes-lab.com/records/lex/reversible-deployment.md): The requirement that a deployment be structured so it can be safely reverted to a prior version.
- [Versioned Artifact](https://banes-lab.com/records/lex/versioned-artifact.md): A build artifact tagged with a distinct version so a prior one can be redeployed.
- [In-Place Mutation Only](https://banes-lab.com/records/lex/in-place-mutation-only.md): Upgrading by mutating the running environment in place, with no parallel target to cut over to or fall back from.
- [Infrastructure Cost](https://banes-lab.com/records/lex/infrastructure-cost.md): The degree to which running two full parallel environments doubles infrastructure cost during a cutover.
- [Low-Risk Cutover](https://banes-lab.com/records/lex/low-risk-cutover.md): The ability to switch traffic to a new version with low risk by keeping the old one ready to fall back to.
- [Parallel Environments](https://banes-lab.com/records/lex/parallel-environments.md): The requirement that two full production-equivalent environments run side by side for cutover.
- [Big-Bang Deployment](https://banes-lab.com/records/lex/big-bang-deployment.md): Releasing a change to all users at once with no gradual exposure, so a defect reaches all of them.
- [Controlled Exposure](https://banes-lab.com/records/lex/controlled-exposure.md): The ability to expose a new version to a small, controlled fraction of traffic first.
- [Progressive Delivery](https://banes-lab.com/records/lex/progressive-delivery.md): A release strategy that rolls out changes gradually to widening audiences while monitoring for regressions.
- [Rollout Complexity](https://banes-lab.com/records/lex/rollout-complexity.md): The degree to which staging a release in gradual increments adds orchestration complexity.
- [Traffic Splitting](https://banes-lab.com/records/lex/traffic-splitting.md): A facility that routes a configurable proportion of traffic to different versions of a service.
- [Empirical Resilience Verification](https://banes-lab.com/records/lex/empirical-resilience-verification.md): The ability to verify a system's resilience empirically by injecting faults and observing recovery.
- [Production Risk](https://banes-lab.com/records/lex/production-risk.md): The degree to which deliberately injecting faults in production risks causing user-facing incidents.
- [Untested Failure Assumptions](https://banes-lab.com/records/lex/untested-failure-assumptions.md): Assuming a system will survive failures without ever testing those assumptions against injected faults.
- [Connection Cleanup](https://banes-lab.com/records/lex/connection-cleanup.md): The ability to close open connections cleanly when a process shuts down.
- [Hard Process Kill](https://banes-lab.com/records/lex/hard-process-kill.md): Terminating a process abruptly without draining work, dropping in-flight requests and risking corrupt state.
- [In-Flight Work Drain](https://banes-lab.com/records/lex/in-flight-work-drain.md): The ability to finish or safely hand off in-progress work before a process exits.
- [Lifecycle Signals](https://banes-lab.com/records/lex/lifecycle-signals.md): The requirement that a process receive lifecycle signals telling it when to start draining and stop.
- [Shutdown Latency](https://banes-lab.com/records/lex/shutdown-latency.md): The degree to which draining in-flight work before exit lengthens the time a shutdown takes.
- [Disk-Failure Survival](https://banes-lab.com/records/lex/disk-failure-survival.md): The ability to keep serving data after one or more disks fail, by reconstructing from redundancy.
- [Multiple Physical Disks](https://banes-lab.com/records/lex/multiple-physical-disks.md): The requirement that data span several physical disks so redundancy can survive a single-disk loss.
- [Parity-Based Recovery](https://banes-lab.com/records/lex/parity-based-recovery.md): The ability to reconstruct lost data from parity information stored across the disk array.
- [Single-Disk Point of Failure](https://banes-lab.com/records/lex/single-disk-point-of-failure.md): Storing data on a single disk with no redundancy, so that one disk's failure loses everything.
- [Write Amplification](https://banes-lab.com/records/lex/write-amplification.md): The degree to which maintaining parity on writes multiplies the underlying disk writes for each logical write.
- [Broken Inheritance](https://banes-lab.com/records/lex/broken-inheritance.md): A subclass that violates its base type's contract, so substituting it breaks callers that rely on the base behavior.
- [Concrete Dependency](https://banes-lab.com/records/lex/concrete-dependency.md): Depending directly on a concrete implementation instead of an abstraction, coupling high-level code to low-level detail.
- [Fat Interface](https://banes-lab.com/records/lex/fat-interface.md): An interface bundling many unrelated operations, forcing clients to depend on methods they never call.
- [Incompatible Override](https://banes-lab.com/records/lex/incompatible-override.md): An override that changes a method's expected inputs or outputs, breaking the substitutability of the subtype.
- [Switch-Based Extension](https://banes-lab.com/records/lex/switch-based-extension.md): Extending behavior by editing a growing switch or conditional on a type instead of adding a new polymorphic type.
- [Type Switching](https://banes-lab.com/records/lex/type-switching.md): Branching on an object's concrete type instead of dispatching through a shared polymorphic interface.
- [Consumer-Specific Contracts](https://banes-lab.com/records/lex/consumer-specific-contracts.md): The ability to give each client an interface exposing only the operations it uses.
- [Feature Extension without Modification](https://banes-lab.com/records/lex/feature-extension-without-modification.md): The ability to add new behavior by writing new code rather than editing existing, tested code.
- [Contract Preservation](https://banes-lab.com/records/lex/contract-preservation.md): The requirement that a subtype honor every behavioral guarantee of the type it replaces.
- [Role-Specific Interfaces](https://banes-lab.com/records/lex/role-specific-interfaces.md): The requirement that interfaces be defined per client role rather than as one general-purpose surface.
- [Interface Proliferation](https://banes-lab.com/records/lex/interface-proliferation.md): The degree to which splitting interfaces finely multiplies the number of small interfaces to manage.
- [Narrow Specialized Behavior](https://banes-lab.com/records/lex/narrow-specialized-behavior.md): The degree to which honoring a base type's contract constrains a subtype from specializing its own behavior.
- [Batch-Only Processing](https://banes-lab.com/records/lex/batch-only-processing.md): Processing data in scheduled batches rather than as a continuous low-latency stream.
- [Ordering/State](https://banes-lab.com/records/lex/ordering-state.md): The degree to which processing an unbounded stream complicates preserving event order and bounded state.
- [Forward-Only State Model](https://banes-lab.com/records/lex/forward-only-state-model.md): The requirement that processing keep only forward-moving state, never needing to revisit earlier input.
- [Global Optimization](https://banes-lab.com/records/lex/global-optimization.md): The degree to which processing data in a single pass forgoes optimizations that need a full view of the data.
- [Multi-Pass Full Materialization](https://banes-lab.com/records/lex/multi-pass-full-materialization.md): Loading a full dataset into memory and traversing it in multiple passes, rather than in a single streaming pass.
- [Error Propagation/Debugging](https://banes-lab.com/records/lex/error-propagation-debugging.md): The degree to which splitting work into pipeline stages makes an error harder to trace back to its origin.
- [Monolithic Processing Function](https://banes-lab.com/records/lex/monolithic-processing-function.md): One large function that performs every processing step at once, so stages cannot be tested or reused independently.
- [Stage Contracts](https://banes-lab.com/records/lex/stage-contracts.md): The requirement that each pipeline stage declare a typed contract for what it consumes and produces.
- [Stepwise Transformation](https://banes-lab.com/records/lex/stepwise-transformation.md): The ability to transform data through a sequence of small, composable stages.
- [Streaming](https://banes-lab.com/records/lex/streaming.md): The ability to process data continuously as it arrives rather than in complete batches.
- [Avoiding Unneeded Work](https://banes-lab.com/records/lex/avoiding-unneeded-work.md): The ability to skip computing results that are never used.
- [Debuggability/Resource Lifetime](https://banes-lab.com/records/lex/debuggability-resource-lifetime.md): The degree to which deferring computation makes execution order harder to debug and resource lifetimes harder to reason about.
- [Deferred Execution Semantics](https://banes-lab.com/records/lex/deferred-execution-semantics.md): The requirement that a computation's semantics defer its work until the result is demanded.
- [Eager Full Materialization](https://banes-lab.com/records/lex/eager-full-materialization.md): Computing and materializing a complete result up front, rather than deferring computation until parts are needed.
- [Large Data Processing](https://banes-lab.com/records/lex/large-data-processing.md): The ability to process datasets larger than memory by reading them in order, a piece at a time.
- [Lookup Performance](https://banes-lab.com/records/lex/lookup-performance.md): The degree to which reading strictly in sequence makes locating a specific item by key slow.
- [Ordered Read Model](https://banes-lab.com/records/lex/ordered-read-model.md): The requirement that data be read in a fixed forward order rather than by arbitrary index.
- [Random Access Requirement](https://banes-lab.com/records/lex/random-access-requirement.md): A need to read arbitrary items by position or key on demand rather than strictly in sequence.
- [Backtracking Algorithm](https://banes-lab.com/records/lex/backtracking-algorithm.md): A method that explores options and reverts to an earlier point when one fails, requiring the ability to look back.
- [Complex Grammar/Global State](https://banes-lab.com/records/lex/complex-grammar-global-state.md): The degree to which forbidding backtracking makes complex grammars or global-state logic hard to express.
- [No Backtracking Requirement](https://banes-lab.com/records/lex/no-backtracking-requirement.md): The requirement that processing never need to revisit earlier input to make a decision.
- [Streaming Parsers](https://banes-lab.com/records/lex/streaming-parsers.md): The ability to parse input incrementally as it streams in, without buffering the whole document.
- [Control-Flow-Centric Monolith](https://banes-lab.com/records/lex/control-flow-centric-monolith.md): A monolith driven by imperative control flow rather than data dependencies, so stages cannot run or scale independently.
- [Data Dependencies](https://banes-lab.com/records/lex/data-dependencies.md): The requirement that the data each stage needs from others be declared as explicit dependencies.
- [Parallel/Stream Processing](https://banes-lab.com/records/lex/parallel-stream-processing.md): The ability to run independent stages in parallel or stream data between them as it is produced.
- [Stages](https://banes-lab.com/records/lex/stages.md): The requirement that processing be decomposed into discrete stages connected by data flow.
- [State Coordination](https://banes-lab.com/records/lex/state-coordination.md): The degree to which a data-driven design must still coordinate shared state across concurrent stages.
- [No Hidden State](https://banes-lab.com/records/lex/no-hidden-state.md): The requirement that a processor keep no state hidden between invocations, taking all inputs explicitly.
- [Parallel Processing](https://banes-lab.com/records/lex/parallel-processing.md): The ability to process many records at once because each is handled independently of the others.
- [Stateful Business Rules](https://banes-lab.com/records/lex/stateful-business-rules.md): The degree to which rules that inherently depend on accumulated state resist a purely stateless design.
- [Stateful Hidden Accumulation](https://banes-lab.com/records/lex/stateful-hidden-accumulation.md): Accumulating state inside a processor across records, so results depend on invisible history.
- [Bounded Aggregation over Unbounded Streams](https://banes-lab.com/records/lex/bounded-aggregation-over-unbounded-streams.md): The ability to aggregate an endless stream by grouping its events into bounded windows.
- [Bounded State](https://banes-lab.com/records/lex/bounded-state.md): The degree to which processing keeps its working state within a fixed bound regardless of input size.
- [Event Time](https://banes-lab.com/records/lex/event-time.md): The time at which an event occurred, carried on the event and used to assign it to a window.
- [Late-Data Handling](https://banes-lab.com/records/lex/late-data-handling.md): The degree to which windowing by event time must reckon with events that arrive after their window has closed.
- [Unbounded Accumulation](https://banes-lab.com/records/lex/unbounded-accumulation.md): Aggregating an endless stream into ever-growing state that eventually exhausts memory.
- [Parallel Branch Processing](https://banes-lab.com/records/lex/parallel-branch-processing.md): The ability to process independent branches of work simultaneously across workers.
- [Result Aggregation](https://banes-lab.com/records/lex/result-aggregation.md): The ability to combine the outputs of parallel branches back into a single result.
- [Serial Item Processing](https://banes-lab.com/records/lex/serial-item-processing.md): Processing independent items one at a time in sequence, rather than in parallel.
- [Fitness for Purpose](https://banes-lab.com/records/lex/fitness-for-purpose.md): The degree to which the chosen processing model matches the latency and volume the problem needs.
- [Latency Requirement Clarity](https://banes-lab.com/records/lex/latency-requirement-clarity.md): The requirement that a workload's latency and freshness needs be made explicit before a processing model is chosen.
- [Latency-Appropriate Processing Model](https://banes-lab.com/records/lex/latency-appropriate-processing-model.md): The ability to choose batch or stream processing to match a workload's latency needs.
- [One-Size-Fits-All Processing](https://banes-lab.com/records/lex/one-size-fits-all-processing.md): Forcing every workload through a single processing model regardless of its latency or volume needs.
- [Operational Duplication](https://banes-lab.com/records/lex/operational-duplication.md): The degree to which supporting both batch and streaming paths duplicates operational effort and code.
- [Cartesian Inheritance Explosion](https://banes-lab.com/records/lex/cartesian-inheritance-explosion.md): Modeling every combination of two independent dimensions as its own subclass, so the class count grows multiplicatively.
- [Direct Access](https://banes-lab.com/records/lex/direct-access.md): Reaching a resource directly with no intermediary, bypassing the access control, caching, or laziness a proxy would add.
- [Direct External Coupling](https://banes-lab.com/records/lex/direct-external-coupling.md): Coupling code directly to an incompatible external interface, spreading its idiosyncrasies through the codebase.
- [Leaf-vs-Container Special-Casing](https://banes-lab.com/records/lex/leaf-vs-container-special-casing.md): Branching client code on whether an element is a leaf or a container instead of treating them through one interface.
- [Leaky Subsystem API](https://banes-lab.com/records/lex/leaky-subsystem-api.md): Exposing a subsystem's internal complexity directly to clients instead of hiding it behind a simplifying interface.
- [Per-Instance Duplicate State](https://banes-lab.com/records/lex/per-instance-duplicate-state.md): Storing identical shared state separately in every object instance, wasting memory at high object counts.
- [Subclass Explosion](https://banes-lab.com/records/lex/subclass-explosion.md): Creating a distinct subclass for every combination of optional features instead of composing them at runtime.
- [High-Cardinality Object Reuse](https://banes-lab.com/records/lex/high-cardinality-object-reuse.md): The ability to represent large numbers of similar objects economically by sharing their common intrinsic state.
- [Implementation Swap](https://banes-lab.com/records/lex/implementation-swap.md): The ability to change an abstraction's underlying implementation without altering the abstraction itself.
- [Lazy Load](https://banes-lab.com/records/lex/lazy-load.md): The ability to defer creating or loading a costly resource until it is first used.
- [Leaf/Composite Transparency](https://banes-lab.com/records/lex/leaf-composite-transparency.md): The ability to treat individual objects and compositions of objects through one uniform interface.
- [Recursive Composition](https://banes-lab.com/records/lex/recursive-composition.md): The ability to build tree structures in which composites contain other composites to arbitrary depth.
- [Runtime Behavior Extension](https://banes-lab.com/records/lex/runtime-behavior-extension.md): The ability to add responsibilities to an object dynamically at runtime by wrapping it.
- [Shared Immutable State](https://banes-lab.com/records/lex/shared-immutable-state.md): The ability to safely share one immutable state object across many contexts at once.
- [Simplified Access](https://banes-lab.com/records/lex/simplified-access.md): The ability to use a complex subsystem through a small, convenient interface.
- [Remote Stub](https://banes-lab.com/records/lex/remote-stub.md): A local stand-in object that forwards calls to an object living in another process or machine.
- [Common Interface](https://banes-lab.com/records/lex/common-interface.md): The requirement that a wrapper and the object it wraps share one interface so they remain interchangeable.
- [Incompatible Interfaces](https://banes-lab.com/records/lex/incompatible-interfaces.md): A precondition of two interfaces that must cooperate yet expose mismatched signatures.
- [Independent Variation Axes](https://banes-lab.com/records/lex/independent-variation-axes.md): The requirement that an abstraction and its implementation vary along separate axes so they can be decoupled.
- [Separable Intrinsic State](https://banes-lab.com/records/lex/separable-intrinsic-state.md): The requirement that an object's shared, context-independent state be separable from its per-use state.
- [Uniform Component Interface](https://banes-lab.com/records/lex/uniform-component-interface.md): The requirement that leaves and composites implement one shared interface so clients treat them alike.
- [Indirection](https://banes-lab.com/records/lex/indirection.md): The degree of extra indirection introduced by separating an abstraction from its implementation.
- [Over-Centralization](https://banes-lab.com/records/lex/over-centralization.md): The degree to which routing all access through one facade concentrates responsibility and can bottleneck change.
- [Stack Debugging](https://banes-lab.com/records/lex/stack-debugging.md): The degree to which layers of wrapping deepen the call stack and complicate debugging.
- [Subsystem Complexity](https://banes-lab.com/records/lex/subsystem-complexity.md): The degree of internal complexity in a subsystem that motivates hiding it behind a facade.
- [Transparency / Debugging](https://banes-lab.com/records/lex/transparency-debugging.md): The degree to which interposing a proxy hides the real object and complicates tracing calls to it.
- [Concern Tag](https://banes-lab.com/records/lex/concern-tag.md): A formal definition of the role a file plays, drawn from the closed concern vocabulary and carried as the last dot-segment before the extension.
- [Subject Slot](https://banes-lab.com/records/lex/subject-slot.md): A facility that names who or what a file serves, occupying the first dot-segment of the filename.
- [Variant Slot](https://banes-lab.com/records/lex/variant-slot.md): A facility that narrows a subject to one facet, occupying the segment between subject and concern and present only on collision or facet ambiguity.
- [Container Level](https://banes-lab.com/records/lex/container-level.md): A facility that partitions a governed root by grouping axis, declared as a closed set and anchoring the depth count at level one.
- [Concern Folder](https://banes-lab.com/records/lex/concern-folder.md): A facility that holds every file of one concern and whose label the file's concern tag must equal.
- [Subject Folder](https://banes-lab.com/records/lex/subject-folder.md): A facility that separates two sets of one concern under a container, present if and only if the sets must not merge.
- [Governed Root](https://banes-lab.com/records/lex/governed-root.md): A rule or precondition that a path falls under the taxonomy only where its root is declared, so an undeclared tree is ungoverned and a declared one is governed in full.
- [Flat Bucket](https://banes-lab.com/records/lex/flat-bucket.md): A facility that holds one collection concern as files with no folders beneath it, declared rather than inferred from shape.
- [Ignore Declaration](https://banes-lab.com/records/lex/ignore-declaration.md): Descriptive data about the names skipped wherever they appear under a governed root, covering build output, vendored sources, tool caches and ecosystem-fixed names.
- [Depth Cap](https://banes-lab.com/records/lex/depth-cap.md): A rule or precondition that every governed file resolve within a fixed number of folders from its governed root, the container included and the file excluded.
- [Ordered Role Sequence](https://banes-lab.com/records/lex/ordered-role-sequence.md): A rule or precondition that each folder depth consume a role strictly later than the depth before it, so container, subject and concern may be skipped but never repeated and never revisited.
- [Layer Spine](https://banes-lab.com/records/lex/layer-spine.md): A conceptual representation of the system-decomposition spectrum that totally orders every concern from domain through product and supplies the tie-break direction.
- [Collection Concern](https://banes-lab.com/records/lex/collection-concern.md): A formal definition of a concern whose file defines many members at once, plural in both the folder label and the file tag.
- [Single-Unit Concern](https://banes-lab.com/records/lex/single-unit-concern.md): A formal definition of a concern with one instance per file, pairing a plural folder label with a singular file tag.
- [Glob Resolvability](https://banes-lab.com/records/lex/glob-resolvability.md): The degree to which one depth-unanchored pattern resolves every file or every folder of a concern across the whole tree.
- [Placement Predictability](https://banes-lab.com/records/lex/placement-predictability.md): The degree to which a file's correct location is derivable from its role alone, with exactly one legal answer.
- [Naming Expressiveness](https://banes-lab.com/records/lex/naming-expressiveness.md): The degree to which a closed vocabulary limits how precisely the developer can name a file that its declared words do not yet cover.
- [Tree Compactness](https://banes-lab.com/records/lex/tree-compactness.md): The degree to which a small module can stay in few files and folders rather than expanding into one concern folder per role.
- [Classification Judgment](https://banes-lab.com/records/lex/classification-judgment.md): The activity of reading a file and assigning its concern by its primary responsibility, which no pattern-match can perform on its behalf.
- [Vocabulary Admission](https://banes-lab.com/records/lex/vocabulary-admission.md): The act of reasoning a proposed word against the declared categories and admitting it only by developer-approved registry edit.
- [Identity Migration](https://banes-lab.com/records/lex/identity-migration.md): The activity of renaming an artifact and updating every reference to it in the same pass, so no reference is left dangling.
- [Shape-Discovered Surface](https://banes-lab.com/records/lex/shape-discovered-surface.md): A facility that collects its members by matching a pattern rather than by literal path, so a rename silently changes what it collects.
- [Container-by-Container Reshape](https://banes-lab.com/records/lex/container-by-container-reshape.md): The practice of converting one container at a time to the taxonomy, updating every reference in the same pass and holding the gate green between each.
- [Is-A Test](https://banes-lab.com/records/lex/is-a-test.md): A technique for deciding concern membership by asking whether a file is-a the proposed word, admitting it as a role when it is and as a domain noun when the system merely has-a it.
- [Rejection Table](https://banes-lab.com/records/lex/rejection-table.md): A formal definition of each near-miss word already considered and refused, recording the meta concern that covers it so the same word is not proposed twice.
- [Covering Concern](https://banes-lab.com/records/lex/covering-concern.md): A formal definition of the declared word that already fills a proposed word's role, resolved from the rejection table so a refusal carries its own replacement.
- [Reverse Coverage Resolution](https://banes-lab.com/records/lex/reverse-coverage-resolution.md): A technique for answering which declared words cover a candidate, by indexing the rejection table on its refused words rather than on the concerns they map to.
- [Free-Form Folder Level](https://banes-lab.com/records/lex/free-form-folder-level.md): A folder level resolving to no declared word, so the path is conventional rather than checkable and classification has more than one right answer.
- [Unguided Refusal](https://banes-lab.com/records/lex/unguided-refusal.md): Reporting an undeclared word without naming the declared word that covers it, so the developer's or the model's next attempt is another guess and the closed set reads as an obstacle rather than a map.
- [Borrowed Synonymy](https://banes-lab.com/records/lex/borrowed-synonymy.md): Deciding whether two declared words overlap from a general-language corpus rather than from the roles they name, so distinct concerns collide on their everyday senses and domain overlaps go unseen.
- [Vocabulary Inflation](https://banes-lab.com/records/lex/vocabulary-inflation.md): Adding a word to the closed vocabulary so a check passes, admitting a synonym, an abbreviation, or a process-name for something already declared.
- [Ignore-List Silencing](https://banes-lab.com/records/lex/ignore-list-silencing.md): Answering a finding by adding the path to the ignore declaration, removing authored source from the taxonomy entirely and hiding every future violation under the same name.
- [Depth-Relief Container](https://banes-lab.com/records/lex/depth-relief-container.md): Declaring a container to shorten a path or to house files that resist placement, turning the level that anchors the depth count into an escape from it.
- [Restated Set Member](https://banes-lab.com/records/lex/restated-set-member.md): Naming a file with the subject its folder already declares, so the member repeats the set and the name carries no information.
- [Saturated Role Tag](https://banes-lab.com/records/lex/saturated-role-tag.md): Classifying a file under a label naming a stature rather than a role, so it attaches to lifecycle owners, caches, registries and coordinators alike and excludes nothing.
- [Concern-Swallowing Compound](https://banes-lab.com/records/lex/concern-swallowing-compound.md): Fusing a subject and a concern into one word, so the tag that should terminate the name is buried inside it and no glob resolves the file.
- [Downward Nesting](https://banes-lab.com/records/lex/downward-nesting.md): Relieving collision or breadth pressure by adding a folder level, breaking the depth cap that both overflow slots exist to protect.
- [Automated Reshape](https://banes-lab.com/records/lex/automated-reshape.md): Renaming by tool across a tree holding shape-discovered surfaces, so the rewrite reports clean while an aggregator that collected by suffix now collects nothing.
- [Nominalized Process Word](https://banes-lab.com/records/lex/nominalized-process-word.md): Admitting a word naming what the system does rather than what it has, so the vocabulary accumulates verbs and adjectives that classify nothing.
- [Multi-Role File](https://banes-lab.com/records/lex/multi-role-file.md): Keeping a file whose primary responsibility is two concerns, forcing an arbitrary tag instead of surfacing the split the ambiguity reports.
- [Reasoning in the Registry](https://banes-lab.com/records/lex/reasoning-in-the-registry.md): Writing the rules about a declaration into the declaration file itself, producing a document in a schema's format that no code reads.
- [Idempotency Key or Deterministic Operation](https://banes-lab.com/records/lex/idempotency-key-or-deterministic-operation.md): The requirement that an operation carry a deduplication key or be deterministic so repeating it is safe.
- [Non-Repeatable Side Effects](https://banes-lab.com/records/lex/non-repeatable-side-effects.md): Side effects whose repetition changes the outcome, so retrying an operation double-applies them.
- [Safe Retries](https://banes-lab.com/records/lex/safe-retries.md): The ability to retry an operation without fear of duplicating its effects.
- [State Tracking](https://banes-lab.com/records/lex/state-tracking.md): The degree to which making operations idempotent requires tracking processed keys or prior state.
- [All-or-Nothing State Change](https://banes-lab.com/records/lex/all-or-nothing-state-change.md): The ability to apply a set of changes so that either all of them take effect or none do.
- [Distributed Scalability](https://banes-lab.com/records/lex/distributed-scalability.md): The degree to which enforcing atomic transactions across nodes limits how far a system can scale out.
- [Partial Commit](https://banes-lab.com/records/lex/partial-commit.md): Committing only some of a multi-step change after a failure, leaving state half-updated and inconsistent.
- [BASE/Eventual Consistency](https://banes-lab.com/records/lex/base-eventual-consistency.md): A consistency model favoring availability and soft state, letting replicas converge over time rather than staying strongly consistent.
- [Distributed Availability](https://banes-lab.com/records/lex/distributed-availability.md): The degree to which insisting on strong transactional consistency reduces availability across a distributed system.
- [Durability](https://banes-lab.com/records/lex/durability.md): The degree to which committed data survives crashes and is never lost once acknowledged.
- [Strong Transactional Guarantees](https://banes-lab.com/records/lex/strong-transactional-guarantees.md): The ability to guarantee that a group of operations is atomic, consistent, isolated, and durable.
- [Consistency Rules](https://banes-lab.com/records/lex/consistency-rules.md): The requirement that the invariants a transaction must preserve be defined for its scope.
- [Hidden Distributed Transaction](https://banes-lab.com/records/lex/hidden-distributed-transaction.md): A transaction that silently spans service boundaries, coupling systems that should commit independently.
- [Large Transaction Scope](https://banes-lab.com/records/lex/large-transaction-scope.md): The degree to which widening a transaction to cover more work increases contention and failure surface.
- [Safe State Mutation](https://banes-lab.com/records/lex/safe-state-mutation.md): The ability to mutate state within a bounded transaction so partial failures cannot corrupt it.
- [Coordinated Persistence](https://banes-lab.com/records/lex/coordinated-persistence.md): The ability to commit a set of related changes together as one atomic unit of work.
- [Repository Complexity](https://banes-lab.com/records/lex/repository-complexity.md): The degree to which coordinating saves through a unit of work adds indirection to the persistence layer.
- [Scattered Save Calls](https://banes-lab.com/records/lex/scattered-save-calls.md): Persisting related changes through many independent save calls, so a mid-sequence failure leaves partial state.
- [Inconsistent Replicas/Models](https://banes-lab.com/records/lex/inconsistent-replicas-models.md): Replicas or models that disagree on the same data, so reads return conflicting answers.
- [Reliable State](https://banes-lab.com/records/lex/reliable-state.md): The ability to trust that stored state always satisfies its invariants.
- [Dirty Reads/Writes](https://banes-lab.com/records/lex/dirty-reads-writes.md): Reading or overwriting another transaction's uncommitted changes, so a rollback leaves corrupt data.
- [Safe Concurrent Operations](https://banes-lab.com/records/lex/safe-concurrent-operations.md): The ability to run concurrent transactions without their intermediate states interfering.
- [Safe Parallel Mutation](https://banes-lab.com/records/lex/safe-parallel-mutation.md): The ability to let multiple actors mutate shared state in parallel without corrupting it.
- [Shared State Identification](https://banes-lab.com/records/lex/shared-state-identification.md): The requirement that all state shared between concurrent actors be identified before it is guarded.
- [Blind Overwrite](https://banes-lab.com/records/lex/blind-overwrite.md): Writing over another actor's update without checking whether the data changed first, silently losing it.
- [Conflict Detection](https://banes-lab.com/records/lex/conflict-detection.md): The ability to detect that data changed since it was read, so a conflicting write can be rejected.
- [Retry Complexity](https://banes-lab.com/records/lex/retry-complexity.md): The degree to which rejecting conflicting writes pushes retry-and-merge logic onto callers.
- [Version Field](https://banes-lab.com/records/lex/version-field.md): A field on a record whose value changes on each write, used to detect concurrent modification.
- [Deadlocks](https://banes-lab.com/records/lex/deadlocks.md): The degree to which acquiring multiple locks pessimistically risks two holders waiting on each other forever.
- [Lock Ownership](https://banes-lab.com/records/lex/lock-ownership.md): The requirement that a lock be exclusively held by one actor for the duration of a critical section.
- [Lock-Free Throughput](https://banes-lab.com/records/lex/lock-free-throughput.md): The degree to which a design sustains high throughput by coordinating concurrent access without holding locks.
- [Strong Conflict Prevention](https://banes-lab.com/records/lex/strong-conflict-prevention.md): The ability to prevent conflicting updates by locking data before it is modified.
- [Concurrency Safety](https://banes-lab.com/records/lex/concurrency-safety.md): The degree to which isolating state per unit keeps concurrent execution free of races.
- [Data Sharing](https://banes-lab.com/records/lex/data-sharing.md): The degree to which strictly isolating state limits components from directly sharing data.
- [Effect Boundaries](https://banes-lab.com/records/lex/effect-boundaries.md): The requirement that side effects be confined to explicit boundaries rather than scattered through pure logic.
- [Performance Optimization](https://banes-lab.com/records/lex/performance-optimization.md): The degree to which pushing side effects to the edges can forgo in-place optimizations that mutate for speed.
- [Pure Core / Imperative Shell](https://banes-lab.com/records/lex/pure-core-imperative-shell.md): An arrangement that keeps decision logic pure and pushes all side effects to a thin outer shell.
- [Ad-Hoc Lock Ordering](https://banes-lab.com/records/lex/ad-hoc-lock-ordering.md): Ordering lock acquisition by hand-reasoning rather than a proven scheme, inviting deadlock.
- [Concurrency Correctness](https://banes-lab.com/records/lex/concurrency-correctness.md): The degree to which concurrent flows produce correct results free of races and lost updates.
- [Concurrent-Flow Modeling](https://banes-lab.com/records/lex/concurrent-flow-modeling.md): The ability to model concurrent token flow explicitly so its behavior can be analyzed.
- [Deadlock Freedom](https://banes-lab.com/records/lex/deadlock-freedom.md): The degree to which a concurrent design is provably free of states where progress halts permanently.
- [Modeling Overhead](https://banes-lab.com/records/lex/modeling-overhead.md): The degree to which formally modeling concurrency as a net adds effort over writing the code directly.
- [Places and Transitions](https://banes-lab.com/records/lex/places-and-transitions.md): The requirement that a modeled system be expressed as places holding tokens and transitions that move them.
- [Reachability and Deadlock Analysis](https://banes-lab.com/records/lex/reachability-and-deadlock-analysis.md): The ability to analyze which states a concurrent model can reach and whether any of them deadlock.