# Lexicon terms, part 2 of 5

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

## Entries

- [Cross-System Communication](https://banes-lab.com/records/lexicon/cross-system-communication.md): The ability for independent systems to exchange and understand data with one another.
- [Incremental Deployment](https://banes-lab.com/records/lexicon/incremental-deployment.md): The ability to roll out changes gradually while old and new versions coexist.
- [Independent Consumers](https://banes-lab.com/records/lexicon/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/lexicon/multi-client-integration.md): The ability to serve many different clients through one compatible protocol.
- [Provider Change Safety](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/consumer-safety.md): The degree to which consumers are protected from breakage when a provider changes.
- [Data Quality](https://banes-lab.com/records/lexicon/data-quality.md): The degree to which data is accurate, complete, and fit for its intended use.
- [Integration](https://banes-lab.com/records/lexicon/integration.md): The degree to which separate systems are connected to operate as a unified whole.
- [Cleanup / Simplification](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/development-speed.md): The rate at which new functionality is built, which upfront contract rigor can slow.
- [Distributed Evolution](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/evolution-speed.md): The rate at which an interface can change, which a commitment to stability deliberately limits.
- [Flexibility](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/interface-overuse.md): The degree to which excessive interface abstraction adds indirection without proportional benefit.
- [Permissive APIs](https://banes-lab.com/records/lexicon/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/lexicon/protocol-optimization.md): The degree to which a protocol is tuned for performance, traded against broad compatibility.
- [Provider Autonomy](https://banes-lab.com/records/lexicon/provider-autonomy.md): The degree of freedom a provider retains to change, constrained by consumer-driven contracts.
- [Rapid Prototyping](https://banes-lab.com/records/lexicon/rapid-prototyping.md): The activity of building quick throwaway prototypes, which explicit contracts can slow.
- [Runtime Cost](https://banes-lab.com/records/lexicon/runtime-cost.md): The degree of runtime overhead incurred by checking conditions on every call.
- [Schema Flexibility](https://banes-lab.com/records/lexicon/schema-flexibility.md): The degree to which a schema tolerates variation, in tension with a strict contract.
- [Specialized Endpoints](https://banes-lab.com/records/lexicon/specialized-endpoints.md): The degree to which purpose-built endpoints are offered, traded against a uniform interface.
- [Strong Validation](https://banes-lab.com/records/lexicon/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/lexicon/version-sprawl.md): The degree to which many concurrent versions accumulate and must be maintained.
- [Standard Error Contract](https://banes-lab.com/records/lexicon/standard-error-contract.md): A technique for giving every error one published shape with a code, a message and its context.
- [Introduce Boundary DTO](https://banes-lab.com/records/lexicon/introduce-boundary-dto.md): A technique for carrying data across a boundary in a transfer object, so internal models stay inside.
- [Coarse-Grained Endpoint](https://banes-lab.com/records/lexicon/coarse-grained-endpoint.md): A technique for serving one client operation with one call that returns everything the operation needs.
- [Backward-Compatible Change](https://banes-lab.com/records/lexicon/backward-compatible-change.md): A technique for changing a contract only by additions that existing consumers can ignore.
- [Compatibility Adapter](https://banes-lab.com/records/lexicon/compatibility-adapter.md): A technique for serving an old contract through an adapter over the new one while consumers migrate.
- [Gradual Deprecation](https://banes-lab.com/records/lexicon/gradual-deprecation.md): A technique for announcing a removal with a date, warning the consumers still using it, and removing it after the date.
- [Migration Guide](https://banes-lab.com/records/lexicon/migration-guide.md): A technique for publishing the steps a consumer takes to move from one version of a contract to the next.
- [Version Bump](https://banes-lab.com/records/lexicon/version-bump.md): A technique for raising a contract's version number by the rule that says which kind of change it carries.
- [Consumer-Driven Contract Tests](https://banes-lab.com/records/lexicon/consumer-driven-contract-tests.md): A technique for having each consumer publish the responses it relies on and testing the provider against all of them before it releases.
- [Define Contract](https://banes-lab.com/records/lexicon/define-contract.md): A technique for publishing the operations, shapes and guarantees of a boundary before implementing either side of it.
- [Standardize the Interface](https://banes-lab.com/records/lexicon/standardize-the-interface.md): A technique for giving operations of one kind the same naming, shapes and conventions across a system.
- [Tolerant Reader](https://banes-lab.com/records/lexicon/tolerant-reader.md): A technique for reading only the fields a consumer needs and ignoring unknown ones, so additive changes do not break it.
- [Central Orchestrator Bottleneck](https://banes-lab.com/records/lexicon/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/lexicon/centralized-control.md): Concentrating decision-making authority in one place so nodes cannot act independently.
- [Fully Decentralized Control](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/scattered-auth-implementations.md): Reimplementing authentication separately in each service instead of centralizing it.
- [Scattered Configuration](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/cross-service-analysis.md): The ability to analyze behavior across services by querying their aggregated logs.
- [Independent Ownership](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/single-writer-coordination.md): The ability to designate one writer for each unit of shared state, whether an elected node or the party a record names, so updates to it need no further coordination.
- [Unified Config Management](https://banes-lab.com/records/lexicon/unified-config-management.md): The ability to manage all services' configuration from one place.
- [Unified Identity](https://banes-lab.com/records/lexicon/unified-identity.md): The ability to give users one identity recognized across all services.
- [Config Store](https://banes-lab.com/records/lexicon/config-store.md): A central store that holds configuration values for many services to read.
- [Coordinator](https://banes-lab.com/records/lexicon/coordinator.md): A component that directs the steps of a multi-service workflow in order.
- [Identity Provider](https://banes-lab.com/records/lexicon/identity-provider.md): A central service that authenticates identities and issues credentials for others to trust.
- [Log Aggregation](https://banes-lab.com/records/lexicon/log-aggregation.md): A facility that collects logs from many sources into one central store.
- [Management API](https://banes-lab.com/records/lexicon/management-api.md): A programmatic interface through which operators manage a distributed runtime's state.
- [Quorum](https://banes-lab.com/records/lexicon/quorum.md): The requirement that a majority of nodes agree before a decision commits.
- [Central Dependency Risk](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/identity-provider-availability.md): The degree to which every login depends on the central identity provider staying available.
- [Externalize Configuration](https://banes-lab.com/records/lexicon/externalize-configuration.md): A technique for moving values that vary by environment out of code into configuration read at startup.
- [Configuration Schema](https://banes-lab.com/records/lexicon/configuration-schema.md): A technique for validating configuration against a declared schema before the system starts.
- [Assumption-Driven Delivery](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/floating-dependencies.md): Depending on unpinned, floating dependency versions, so builds are not reproducible.
- [Hidden Behavior](https://banes-lab.com/records/lexicon/hidden-behavior.md): Behavior triggered by hidden state or side effects, so outcomes surprise callers.
- [Hidden IO](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/unchecked-dynamic-code.md): Running dynamically generated or evaluated code that static analysis cannot inspect for defects.
- [Undefined Behavior](https://banes-lab.com/records/lexicon/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/lexicon/untested-implementation.md): Shipping code with no tests, so its conformance to the specification is unverified.
- [Behavior Validation](https://banes-lab.com/records/lexicon/behavior-validation.md): The ability to confirm a system behaves as its specification requires.
- [Broad Input Exploration](https://banes-lab.com/records/lexicon/broad-input-exploration.md): The ability to exercise a function across a wide, generated range of inputs.
- [Mathematical Assurance](https://banes-lab.com/records/lexicon/mathematical-assurance.md): The ability to prove mathematically that a system meets its specification.
- [Regression Safety](https://banes-lab.com/records/lexicon/regression-safety.md): The ability to catch regressions when code changes by re-running tests.
- [Reliable Automation](https://banes-lab.com/records/lexicon/reliable-automation.md): The ability to automate a process reliably because it repeats identically each run.
- [Reliable Testing](https://banes-lab.com/records/lexicon/reliable-testing.md): The ability to test dependably because the same inputs always produce the same outputs.
- [Safe Operation](https://banes-lab.com/records/lexicon/safe-operation.md): The ability to operate without producing incorrect or harmful results.
- [Safe Sharing](https://banes-lab.com/records/lexicon/safe-sharing.md): The ability to share data freely across threads because it cannot be modified.
- [Specification Compliance](https://banes-lab.com/records/lexicon/specification-compliance.md): The ability to confirm an implementation conforms to its specification.
- [Formal Specification](https://banes-lab.com/records/lexicon/formal-specification.md): A precise, mathematical statement of what a system must do, against which it is proven.
- [Ruleset](https://banes-lab.com/records/lexicon/ruleset.md): The set of rules a static analyzer checks source code against.
- [Tests](https://banes-lab.com/records/lexicon/tests.md): Executable checks that assert a system behaves as intended.
- [Controlled State](https://banes-lab.com/records/lexicon/controlled-state.md): The requirement that all inputs and state affecting a computation be fixed, bounded or fully specified, so its behavior is reproducible.
- [Deterministic Behavior](https://banes-lab.com/records/lexicon/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/lexicon/no-side-effects.md): The requirement that a function compute its result without observable side effects.
- [Properties/Invariants](https://banes-lab.com/records/lexicon/properties-invariants.md): The requirement that the general properties or invariants a function must satisfy be defined.
- [Value Semantics](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/continuous-updates.md): The degree to which pinning everything for reproducibility conflicts with continuously updating dependencies.
- [Cost/Complexity](https://banes-lab.com/records/lexicon/cost-complexity.md): The degree of cost and complexity added by formally proving a system correct.
- [Dynamic Runtime Behavior](https://banes-lab.com/records/lexicon/dynamic-runtime-behavior.md): The degree to which runtime-adaptive behavior undermines a system's predictability.
- [Encapsulation Extremes](https://banes-lab.com/records/lexicon/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/lexicon/fitness-for-use.md): The degree to which a product meets the needs of its users.
- [Real-World Variability](https://banes-lab.com/records/lexicon/real-world-variability.md): The degree to which controlling conditions for repeatability diverges from real-world variability.
- [Runtime Adaptivity](https://banes-lab.com/records/lexicon/runtime-adaptivity.md): The degree to which making behavior deterministic limits adapting dynamically at runtime.
- [Shrinking/Debug Complexity](https://banes-lab.com/records/lexicon/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/lexicon/spec-maintenance.md): The degree of ongoing effort to keep a specification current as the system evolves.
- [Stateful IO](https://banes-lab.com/records/lexicon/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/lexicon/stateful-operations.md): The degree to which operations that depend on or mutate state conflict with purity.
- [Thread Safety](https://banes-lab.com/records/lexicon/thread-safety.md): The degree to which data can be accessed concurrently without corruption.
- [Make Effects Explicit](https://banes-lab.com/records/lexicon/make-effects-explicit.md): A technique for moving input, output and mutation to named boundary operations, so the code between them stays pure.
- [Pass Context Explicitly](https://banes-lab.com/records/lexicon/pass-context-explicitly.md): A technique for passing request, user or tenant context as a parameter or scoped object instead of reading it from global state.
- [Inject Clock and Randomness](https://banes-lab.com/records/lexicon/inject-clock-and-randomness.md): A technique for supplying time and random values through parameters, so the code under test runs the same way every time.
- [Test Observable Behavior](https://banes-lab.com/records/lexicon/test-observable-behavior.md): A technique for asserting on a unit's outputs and effects instead of on the internal calls it makes.
- [Fake at the Boundary](https://banes-lab.com/records/lexicon/fake-at-the-boundary.md): A technique for replacing an external dependency in tests with a working in-memory implementation of its port.
- [Unit Tests](https://banes-lab.com/records/lexicon/unit-tests.md): A technique for testing one unit of behavior in isolation, fast enough to run on every change.
- [Component Tests](https://banes-lab.com/records/lexicon/component-tests.md): A technique for testing one deployable component through its public interface with its dependencies replaced.
- [Isolate Test State](https://banes-lab.com/records/lexicon/isolate-test-state.md): A technique for giving each test its own data and resources, so tests pass in any order.
- [Validate at the Boundary](https://banes-lab.com/records/lexicon/validate-at-the-boundary.md): A technique for rejecting malformed input where it enters the system, so the core receives only valid values.
- [Encapsulate Validation](https://banes-lab.com/records/lexicon/encapsulate-validation.md): A technique for placing a value's validation in the type that holds it, so every instance is valid.
- [Validate as a Group](https://banes-lab.com/records/lexicon/validate-as-a-group.md): A technique for validating fields that depend on each other together, in the object that groups them.
- [Precondition Check](https://banes-lab.com/records/lexicon/precondition-check.md): A technique for checking at the start of an operation that the state and arguments it requires hold.
- [Invariant Check](https://banes-lab.com/records/lexicon/invariant-check.md): A technique for checking after each change that the rules a state must always satisfy still hold.
- [Postcondition Check](https://banes-lab.com/records/lexicon/postcondition-check.md): A technique for checking at the end of an operation that the result and state it promises hold.
- [Pin Versions](https://banes-lab.com/records/lexicon/pin-versions.md): A technique for recording exact versions of dependencies and tools, so every build uses the same inputs.
- [Ignored Analyzer Findings](https://banes-lab.com/records/lexicon/ignored-analyzer-findings.md): A defect in which static analysis findings are left unresolved until the analyzer's output stops being read.
- [Platform Migration](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/reliable-deployment.md): The ability to deploy with confidence because every environment behaves the same way.
- [Snowflake Environments](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/automated-provisioning.md): The ability to create and configure infrastructure automatically from declarative definitions.
- [Manual Infrastructure Changes](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/proprietary-deviation.md): Deviating from a shared standard with proprietary extensions, breaking interoperability with conformant systems.
- [Adapter/Port Abstraction](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/config-schema.md): A schema defining the structure, types, and defaults of a system's externalized configuration.
- [Config Sprawl](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/deterministic-redeploys.md): The ability to redeploy infrastructure identically every time from one fixed definition.
- [In-Place Server Mutation](https://banes-lab.com/records/lexicon/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/lexicon/instance-replacement-over-mutation.md): The ability to update infrastructure by replacing instances wholesale rather than mutating them in place.
- [Centralized Runtime Control](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/copy-paste-programming.md): Duplicating code by copying and pasting instead of extracting a shared abstraction.
- [Cross-Cutting Leakage](https://banes-lab.com/records/lexicon/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/lexicon/deep-inheritance-hierarchy.md): Stacking many layers of subclassing, so behavior is scattered and fragile to change.
- [Exposed Internals](https://banes-lab.com/records/lexicon/exposed-internals.md): Making a module's internal fields and workings reachable from outside, whether public outright or through trivial getters and setters, so callers depend on details that should be hidden and its invariants go unprotected.
- [Implementation-Specific Contracts](https://banes-lab.com/records/lexicon/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/lexicon/leaky-abstraction.md): An abstraction that forces callers to understand its underlying implementation to use it correctly.
- [Mixed Layers](https://banes-lab.com/records/lexicon/mixed-layers.md): Interleaving different architectural layers' logic in one place instead of keeping each concern separate.
- [Monolithic Procedures](https://banes-lab.com/records/lexicon/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/lexicon/shared-runtime-dependency.md): Coupling supposedly-independent modules through a shared runtime component they all depend on.
- [Tight Coupling](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/independent-testing.md): The ability to test a component in isolation without standing up its collaborators.
- [Internal Refactoring](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/product-lines.md): The ability to build a family of related products from shared, reusable components.
- [Shared Libraries](https://banes-lab.com/records/lexicon/shared-libraries.md): The ability to factor common functionality into libraries reused across projects.
- [Strategy Swap](https://banes-lab.com/records/lexicon/strategy-swap.md): The ability to replace one interchangeable algorithm or implementation, such as a plugin at a declared seam, with another without modifying its host.
- [Vendor Swap](https://banes-lab.com/records/lexicon/vendor-swap.md): The ability to replace one vendor's implementation with another behind a stable interface.
- [Delegation](https://banes-lab.com/records/lexicon/delegation.md): Forwarding work to a contained collaborator object rather than inheriting the behavior.
- [Deep Optimization](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/canonical-source.md): The requirement that each piece of knowledge have one authoritative definition rather than copies.
- [Contract Compatibility](https://banes-lab.com/records/lexicon/contract-compatibility.md): The requirement that every alternative implementation fully honor the same interface contract.
- [Explicit Interfaces](https://banes-lab.com/records/lexicon/explicit-interfaces.md): The requirement that a module interact only through declared interfaces, not its hidden internals.
- [Interface Definition](https://banes-lab.com/records/lexicon/interface-definition.md): The requirement that an abstraction expose a defined interface separate from its implementation.
- [Stable Semantics](https://banes-lab.com/records/lexicon/stable-semantics.md): The requirement that an abstraction's meaning stay consistent even as its implementations change.
- [Coordination Cost](https://banes-lab.com/records/lexicon/coordination-cost.md): The degree of extra coordination required when components are made fully independent.
- [Excessive Fragmentation](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/over-layering.md): The degree to which adding separating layers introduces indirection that outweighs the separation gained.
- [Over-Specialization](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/specialized-optimization.md): The degree to which optimizing for one implementation undermines the ability to swap implementations.
- [Extract Class](https://banes-lab.com/records/lexicon/extract-class.md): A technique for moving a cohesive group of fields and methods out of a class into a new class of their own.
- [Extract Module](https://banes-lab.com/records/lexicon/extract-module.md): A technique for moving one responsibility out of a module into a new module with its own entry point.
- [Split Module](https://banes-lab.com/records/lexicon/split-module.md): A technique for dividing a module into modules that each hold one reason to change.
- [Move Behavior to Its Owner](https://banes-lab.com/records/lexicon/move-behavior-to-its-owner.md): A technique for moving a method or function to the module that owns the data it reads and writes.
- [Extract Function](https://banes-lab.com/records/lexicon/extract-function.md): A technique for moving a fragment of a long function into a named function of its own.
- [Split Method](https://banes-lab.com/records/lexicon/split-method.md): A technique for dividing a method that branches on a flag into one method per behavior.
- [Inline Abstraction](https://banes-lab.com/records/lexicon/inline-abstraction.md): A technique for removing an interface, layer or wrapper that adds no policy and calling its single implementation directly.
- [Hide Delegate](https://banes-lab.com/records/lexicon/hide-delegate.md): A technique for adding a method on an object that forwards to the object behind it, so clients stop navigating the chain.
- [Encapsulate State](https://banes-lab.com/records/lexicon/encapsulate-state.md): A technique for making a module's state private and exposing only operations that keep its rules.
- [Restrict Exports](https://banes-lab.com/records/lexicon/restrict-exports.md): A technique for narrowing a module's public surface to the operations its consumers need.
- [Introduce Parameter Object](https://banes-lab.com/records/lexicon/introduce-parameter-object.md): A technique for replacing a group of parameters that travel together with one named object.
- [Separate Query from Command](https://banes-lab.com/records/lexicon/separate-query-from-command.md): A technique for splitting an operation that both returns data and changes state into a query and a command.
- [Collapse Layers](https://banes-lab.com/records/lexicon/collapse-layers.md): A technique for merging layers that only pass calls through, so a simple operation crosses fewer boundaries.
- [Preserve Only Real Boundaries](https://banes-lab.com/records/lexicon/preserve-only-real-boundaries.md): A technique for keeping an abstraction only where it separates parts that change for different reasons.
- [Split by Domain](https://banes-lab.com/records/lexicon/split-by-domain.md): A technique for dividing a catch-all module into modules named for the domain concepts they serve.
- [Centralize the Rule](https://banes-lab.com/records/lexicon/centralize-the-rule.md): A technique for gathering every copy of one rule into a single definition that the copies are replaced by.
- [Explicit Dependency](https://banes-lab.com/records/lexicon/explicit-dependency.md): A technique for declaring what a module needs as parameters or imports instead of reaching it through global state.
- [Localize Effect](https://banes-lab.com/records/lexicon/localize-effect.md): A technique for confining a change of global behavior to the scope that needs it.
- [Restrict Global Mutation](https://banes-lab.com/records/lexicon/restrict-global-mutation.md): A technique for forbidding writes to global objects outside one owning module.
- [Split Abstraction](https://banes-lab.com/records/lexicon/split-abstraction.md): A technique for dividing an abstraction that grew flags for each caller into abstractions that fit one use each.
- [Define Module Boundaries](https://banes-lab.com/records/lexicon/define-module-boundaries.md): A technique for declaring which module owns each piece of code and which entry points other modules may use.
- [Broken Inheritance](https://banes-lab.com/records/lexicon/broken-inheritance.md): A subclass that violates its base type's contract, for example by an override that changes the expected inputs or outputs, so substituting it breaks callers that rely on the base behavior.
- [Fat Interface](https://banes-lab.com/records/lexicon/fat-interface.md): An interface bundling many unrelated operations, forcing clients to depend on methods they never call.
- [Switch-Based Extension](https://banes-lab.com/records/lexicon/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/lexicon/type-switching.md): Branching on an object's concrete type instead of dispatching through a shared polymorphic interface or a visitor's double dispatch.
- [Consumer-Specific Contracts](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/narrow-specialized-behavior.md): The degree to which honoring a base type's contract constrains a subtype from specializing its own behavior.
- [Extract Interface](https://banes-lab.com/records/lexicon/extract-interface.md): A technique for declaring the operations clients use as an interface, so the clients depend on it instead of on the class.
- [Extract Role Interface](https://banes-lab.com/records/lexicon/extract-role-interface.md): A technique for splitting the operations one client role uses into an interface of their own.
- [Split Interface](https://banes-lab.com/records/lexicon/split-interface.md): A technique for dividing a broad interface into smaller ones, each holding operations that change together.
- [Replace Inheritance with Delegation](https://banes-lab.com/records/lexicon/replace-inheritance-with-delegation.md): A technique for replacing a subclass with a class that holds the former base as a field and forwards to it.
- [Split Hierarchy](https://banes-lab.com/records/lexicon/split-hierarchy.md): A technique for dividing a class hierarchy whose subtypes do not honor one contract into hierarchies that each do.
- [Invert Dependency](https://banes-lab.com/records/lexicon/invert-dependency.md): A technique for making a high-level module own an abstraction that a low-level module implements.
- [CRUD-Only State Persistence](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/broker-event-bus.md): A runtime intermediary that routes messages between publishers and subscribers.
- [Command/Query Separation](https://banes-lab.com/records/lexicon/command-query-separation.md): Separating operations that change state from those that return data, so each method has a single purpose.
- [Consumer](https://banes-lab.com/records/lexicon/consumer.md): A component that receives and processes messages from a queue or topic.
- [Deduplication Key](https://banes-lab.com/records/lexicon/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/lexicon/event-contract.md): The agreed schema and semantics of an event that publishers and subscribers both honor.
- [Event Schema](https://banes-lab.com/records/lexicon/event-schema.md): A formal definition of the structure and fields of an event's payload.
- [Event Semantics](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/immutable-events.md): The requirement that recorded events never change once written, only be appended to.
- [Local Transaction](https://banes-lab.com/records/lexicon/local-transaction.md): A transaction confined to a single service's own datastore, the atomic unit a saga or outbox composes.
- [Message Relay](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/own-data.md): The requirement that each service alone own and control its data store.
- [Publisher](https://banes-lab.com/records/lexicon/publisher.md): A component that emits messages to a topic or bus for subscribers to receive.
- [Reconciliation](https://banes-lab.com/records/lexicon/reconciliation.md): The activity of detecting and resolving divergence between replicas so they converge to a consistent state.
- [Reversible/Compensable Step](https://banes-lab.com/records/lexicon/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/lexicon/routing.md): The ability to direct each message to its correct destination based on topic, key, or rule.
- [Subscriber](https://banes-lab.com/records/lexicon/subscriber.md): A component that registers interest in a topic and receives its messages.
- [Subscriber Model](https://banes-lab.com/records/lexicon/subscriber-model.md): A representation of which consumers subscribe to which topics and how they receive messages.
- [User Expectations](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/consumer-elasticity.md): The ability to add or remove consumers dynamically to match message volume.
- [Cross-Service Communication](https://banes-lab.com/records/lexicon/cross-service-communication.md): The ability for independent services to exchange information without direct coupling.
- [Decoupled Domain Reactions](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/distributed-autonomy.md): The ability for distributed nodes to operate and decide independently without central coordination.
- [Failure Recovery](https://banes-lab.com/records/lexicon/failure-recovery.md): The ability to restore correct operation after a failure through compensation or retry.
- [Fan-Out Notification](https://banes-lab.com/records/lexicon/fan-out-notification.md): The ability to deliver one event to many interested subscribers at once.
- [Long-Running Transactions](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/reprocessing-after-fix.md): The ability to reprocess quarantined messages once the underlying defect is fixed.
- [Safe Message Redelivery](https://banes-lab.com/records/lexicon/safe-message-redelivery.md): The ability to redeliver a message without causing duplicate effects, given idempotent handling.
- [Temporal Modeling](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/at-least-once-delivery-safety.md): The degree to which a message is guaranteed to be delivered at least once, tolerating duplicates.
- [Event Reliability](https://banes-lab.com/records/lexicon/event-reliability.md): The degree to which events are guaranteed to be delivered despite failures.
- [Business Complexity](https://banes-lab.com/records/lexicon/business-complexity.md): The degree of domain intricacy that a coordination mechanism must accommodate.
- [Delivery Ordering](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/state-overhead.md): The degree of extra state a consumer must retain to deduplicate or order messages.
- [Storage Growth](https://banes-lab.com/records/lexicon/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/lexicon/storage-volume.md): The degree to which retaining a full event stream consumes large amounts of storage.
- [Strong Consistency](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/workflow-complexity.md): The degree of intricacy of coordinating a multi-step distributed workflow.
- [Query Projection](https://banes-lab.com/records/lexicon/query-projection.md): A technique for maintaining a read model shaped for one query, updated from the writes it depends on.
- [Introduce Async Event](https://banes-lab.com/records/lexicon/introduce-async-event.md): A technique for replacing a synchronous call that need not complete in the request with an event a consumer handles later.
- [Own Data per Service](https://banes-lab.com/records/lexicon/own-data-per-service.md): A technique for giving each service its own store and letting others reach the data only through its contract.
- [Offset Tracking](https://banes-lab.com/records/lexicon/offset-tracking.md): A technique for recording how far each consumer has read in a stream, so it resumes there and can replay from earlier.
- [Snapshot Compaction](https://banes-lab.com/records/lexicon/snapshot-compaction.md): A technique for periodically storing a snapshot of state derived from a log, so readers replay only the events after it.
- [Non-Replayable Processing](https://banes-lab.com/records/lexicon/non-replayable-processing.md): A defect in which consumed events cannot be read again, so a consumer cannot rebuild its state or recover from a fault.
- [All-Or-Nothing Failure](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/exception-swallowing.md): Catching an exception and silently discarding it, hiding the failure from callers and logs.
- [Fail Open](https://banes-lab.com/records/lexicon/fail-open.md): Granting access or continuing when a security check fails, exposing the system on error.
- [Failure Propagation](https://banes-lab.com/records/lexicon/failure-propagation.md): Letting a failure spread unchecked across component boundaries instead of containing it.
- [Fragile Parsing](https://banes-lab.com/records/lexicon/fragile-parsing.md): Parsing input so rigidly that any minor deviation causes a failure.
- [Non-Idempotent Operation](https://banes-lab.com/records/lexicon/non-idempotent-operation.md): An operation whose repetition changes the result, making it unsafe to retry.
- [Shared Resource Pool](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/trusting-invalid-inputs.md): Assuming inputs are valid and using them without checking, so bad data flows through unguarded.
- [Unbounded Retry](https://banes-lab.com/records/lexicon/unbounded-retry.md): Retrying a failing operation endlessly with no limit, amplifying load and delaying recovery.
- [Unsafe Default Continuation](https://banes-lab.com/records/lexicon/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/lexicon/blast-radius-reduction.md): The ability to contain a failure so it affects only one isolated partition.
- [Bounded Waiting](https://banes-lab.com/records/lexicon/bounded-waiting.md): The ability to guarantee an operation waits no longer than a set limit.
- [Cascading Failure Prevention](https://banes-lab.com/records/lexicon/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/lexicon/continued-operation-under-failure.md): The ability to keep operating correctly despite the failure of some components.
- [Controlled Failure](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/safe-failure.md): The ability to fail without corrupting state or causing further damage.
- [Stability Under Stress](https://banes-lab.com/records/lexicon/stability-under-stress.md): The ability to keep functioning under load spikes and adverse conditions.
- [Transient Failure Recovery](https://banes-lab.com/records/lexicon/transient-failure-recovery.md): The ability to recover from short-lived failures by retrying the operation.
- [Backoff](https://banes-lab.com/records/lexicon/backoff.md): Progressively increasing the wait between retries to avoid overwhelming a recovering dependency.
- [Error Model](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/capacity-signaling.md): The requirement that downstream capacity be signaled upstream so producers adjust their rate.
- [Failure Isolation](https://banes-lab.com/records/lexicon/failure-isolation.md): The requirement that a failure be contained within a boundary so it cannot spread.
- [Failure Threshold](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/resource-isolation.md): The requirement that resources be partitioned so exhaustion in one pool cannot starve others.
- [Strict Output](https://banes-lab.com/records/lexicon/strict-output.md): The requirement that a component emit only strictly conformant, well-formed output.
- [Timeout](https://banes-lab.com/records/lexicon/timeout.md): The requirement that an operation be given a maximum time to complete before being abandoned.
- [Tolerant Input](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/slow-operation-tolerance.md): The degree to which enforcing timeouts sacrifices tolerance for legitimately slow operations.
- [Stability](https://banes-lab.com/records/lexicon/stability.md): The degree to which a system keeps operating steadily without collapsing under load.
- [Stale/Reduced Results](https://banes-lab.com/records/lexicon/stale-reduced-results.md): The degree to which serving a fallback yields stale or reduced-quality results.
- [Strict Validation](https://banes-lab.com/records/lexicon/strict-validation.md): The degree to which rejecting deviant input conflicts with accepting it tolerantly.
- [Verbosity](https://banes-lab.com/records/lexicon/verbosity.md): The degree to which pervasive defensive checks add verbosity and clutter to the code.
- [Introduce Typed Result](https://banes-lab.com/records/lexicon/introduce-typed-result.md): A technique for returning success or a typed error as a value, so callers handle failure through the type system.
- [Translate Errors at the Boundary](https://banes-lab.com/records/lexicon/translate-errors-at-the-boundary.md): A technique for converting vendor and infrastructure errors into the core's own error types where they enter.
- [Idempotency Key](https://banes-lab.com/records/lexicon/idempotency-key.md): A technique for tagging each request with a unique key, so a repeated request is recognized and applied once.
- [Bounded Retry](https://banes-lab.com/records/lexicon/bounded-retry.md): A technique for retrying a failed call a limited number of times with growing delays before giving up.
- [Jitter](https://banes-lab.com/records/lexicon/jitter.md): A technique for adding a random offset to retry delays, so clients that failed together do not retry together.
- [Deadline Propagation](https://banes-lab.com/records/lexicon/deadline-propagation.md): A technique for passing the time left for a request to every call it makes, so downstream work stops when the caller has given up.
- [Cancellation](https://banes-lab.com/records/lexicon/cancellation.md): A technique for letting a caller stop work it no longer needs, releasing the resources that work holds.
- [Load Shedding](https://banes-lab.com/records/lexicon/load-shedding.md): A technique for refusing part of the incoming work when load passes capacity, so the work already accepted completes.
- [Bounded Queue](https://banes-lab.com/records/lexicon/bounded-queue.md): A technique for giving a queue a fixed capacity, so producers are slowed or refused instead of exhausting memory.
- [Fail Fast or Fall Back](https://banes-lab.com/records/lexicon/fail-fast-or-fall-back.md): A technique for deciding per failure whether to stop with an error at once or to continue on a declared fallback.
- [Ad-Hoc Design](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/architecture-criteria.md): The requirement that explicit criteria define what a review judges an architecture against.
- [Architecture Drift](https://banes-lab.com/records/lexicon/architecture-drift.md): Gradual divergence of an implementation from its intended architecture as unreviewed changes accumulate.
- [Architecture Foundation](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/assumption-based-judgment.md): Judging an architecture from untested assumptions instead of measured evidence, yielding unreliable conclusions.
- [Attribute Scenarios](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/blind-change.md): Changing a system without analyzing what the change affects, so unintended consequences go unseen.
- [Change Safety](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/competing-attributes.md): The degree to which improving one quality attribute forces a trade-off against another.
- [Consequences](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/criteria.md): The requirement that explicit, agreed measures define how an assessment reaches its verdict.
- [Current State](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/defect-detection.md): The ability to find defects in a change before it is merged or shipped.
- [Design Criteria](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/documentation-maintenance.md): The degree to which keeping decision records current adds ongoing upkeep effort.
- [Early Defect Prevention](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/easier-refactoring.md): The ability to restructure code more safely because consistent patterns make change predictable.
- [Essential Quality Attributes](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/innovation-autonomy.md): The degree to which enforcing standards constrains teams' freedom to innovate independently.
- [Legacy Constraints](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/operability.md): The degree to which a system is easy to run, monitor, and keep healthy in production.
- [Predictable Evolution](https://banes-lab.com/records/lexicon/predictable-evolution.md): The ability to change a system with confidence that consistent structure keeps outcomes foreseeable.
- [Prioritized Refactoring](https://banes-lab.com/records/lexicon/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/lexicon/problem-decomposition.md): Breaking a problem into fundamental sub-problems that can be reasoned about independently.
- [Quality](https://banes-lab.com/records/lexicon/quality.md): The degree to which a system meets its functional and non-functional expectations.
- [Quality Goals](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/reusable-architecture-guidance.md): A body of proven architectural guidance packaged for reuse across projects.
- [Reuse of Established Patterns](https://banes-lab.com/records/lexicon/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/lexicon/review-standards.md): The requirement that agreed standards define what a code review checks for.
- [Risk Detection](https://banes-lab.com/records/lexicon/risk-detection.md): The ability to surface architectural risks early by reviewing structure before it is built.
- [Standard Patterns](https://banes-lab.com/records/lexicon/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/lexicon/standards-definition.md): A defined, authoritative set of standards that units are expected to conform to.
- [Target State](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/uncoordinated-divergence.md): Teams independently diverging from a shared reference architecture, fragmenting the system into incompatible variants.
- [Unbounded Variation](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/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/lexicon/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/lexicon/rule-maintenance.md): The degree to which keeping fitness-function rules current adds ongoing upkeep effort.
- [Undefined Target](https://banes-lab.com/records/lexicon/undefined-target.md): Attempting to close a gap toward a goal that was never clearly defined, so progress cannot be judged.
- [Delete After Evidence](https://banes-lab.com/records/lexicon/delete-after-evidence.md): A technique for removing code once measurement shows nothing calls it.
- [Deprecation Plan](https://banes-lab.com/records/lexicon/deprecation-plan.md): A technique for recording for each obsolete path its owner, its replacement and its removal date.
- [Assign Owner](https://banes-lab.com/records/lexicon/assign-owner.md): A technique for recording a named owner for each module, risk or rule, who decides on its changes.
- [Severity Classification](https://banes-lab.com/records/lexicon/severity-classification.md): A technique for ranking each finding or risk on a declared scale that sets how soon it is handled.
- [Mitigation Plan](https://banes-lab.com/records/lexicon/mitigation-plan.md): A technique for recording the actions that reduce a risk, with an owner and a date for each.
- [Accepted Risk Record](https://banes-lab.com/records/lexicon/accepted-risk-record.md): A technique for recording a decision to accept a risk with who accepted it and when it is reviewed again.
- [Scheduled Review](https://banes-lab.com/records/lexicon/scheduled-review.md): A technique for setting a date on which a decision, risk or exception is examined again.
- [Risk Register](https://banes-lab.com/records/lexicon/risk-register.md): A technique for keeping every known risk in one list with its owner, severity, mitigation and review date.
- [Decision Record with Alternatives](https://banes-lab.com/records/lexicon/decision-record-with-alternatives.md): A technique for recording a decision together with the options rejected and the forces that decided it.
- [Force Analysis](https://banes-lab.com/records/lexicon/force-analysis.md): A technique for listing the pressures a design must balance before choosing a pattern for it.
- [Trade-Off Matrix](https://banes-lab.com/records/lexicon/trade-off-matrix.md): A technique for scoring candidate designs against the quality attributes that matter for the decision.
- [Quality Scenarios](https://banes-lab.com/records/lexicon/quality-scenarios.md): A technique for stating each quality attribute as a stimulus, a response and a measure the design must meet.
- [Decision Review](https://banes-lab.com/records/lexicon/decision-review.md): A technique for re-examining recorded decisions when the evidence behind them changes.
- [Vertical Slice Proof](https://banes-lab.com/records/lexicon/vertical-slice-proof.md): A technique for proving a design by building one end-to-end path through every layer before generalizing it.
- [Defer Generalization](https://banes-lab.com/records/lexicon/defer-generalization.md): A technique for keeping concrete code until a second real variation shows what the abstraction must cover.
- [Validate Required Forces](https://banes-lab.com/records/lexicon/validate-required-forces.md): A technique for checking that a pattern in use has the boundary rules and contracts the pattern requires.
- [Track Rule Metrics](https://banes-lab.com/records/lexicon/track-rule-metrics.md): A technique for counting violations of each architecture rule over time, so recurrence is visible.
- [Architecture Test](https://banes-lab.com/records/lexicon/architecture-test.md): A technique for expressing a structural rule, such as a dependency direction, as a test that runs in the build.
- [Remove Pattern Shell](https://banes-lab.com/records/lexicon/remove-pattern-shell.md): A technique for deleting the structure of a pattern whose forces are absent, leaving the plain code it wrapped.
- [Duplicate Until the Pattern Stabilizes](https://banes-lab.com/records/lexicon/duplicate-until-the-pattern-stabilizes.md): A technique for tolerating a small duplication until enough cases exist to show the shared shape.
- [Measure Delivery Cost](https://banes-lab.com/records/lexicon/measure-delivery-cost.md): A technique for measuring the time and effort an abstraction adds to delivering a change.
- [Anchor to Use Cases](https://banes-lab.com/records/lexicon/anchor-to-use-cases.md): A technique for justifying each component by a concrete use case it serves.
- [Contextual Pattern Selection](https://banes-lab.com/records/lexicon/contextual-pattern-selection.md): A technique for choosing a pattern by the forces of the problem at hand instead of by familiarity.
- [Dead Code Check](https://banes-lab.com/records/lexicon/dead-code-check.md): A technique for failing the build on exports and branches that nothing reaches.
- [Archive Reference](https://banes-lab.com/records/lexicon/archive-reference.md): A technique for keeping removed code reachable in history or an archive instead of in the live tree.
- [Inconsistent Conventions](https://banes-lab.com/records/lexicon/inconsistent-conventions.md): A defect in which parts of one project use different structures, formats, tools or patterns for the same kind of thing.
- [Excessive Configuration](https://banes-lab.com/records/lexicon/excessive-configuration.md): Requiring explicit configuration for everything instead of relying on sensible conventions.
- [Hardcoded Behavior](https://banes-lab.com/records/lexicon/hardcoded-behavior.md): Hardcoding behavior in code instead of driving it from declarative metadata.
- [Hardcoded Registration](https://banes-lab.com/records/lexicon/hardcoded-registration.md): Registering components with hardcoded wiring instead of declaring them in a manifest.
- [Hidden Runtime Behavior](https://banes-lab.com/records/lexicon/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/lexicon/implicit-capability.md): Leaving what a component can do implicit and undiscoverable instead of declaring it.
- [Opaque API](https://banes-lab.com/records/lexicon/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/lexicon/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/lexicon/client-generation.md): The ability to generate client code automatically from an API's self-description.
- [Dynamic Processing](https://banes-lab.com/records/lexicon/dynamic-processing.md): The ability to process data generically by reading its self-describing structure.