# Architecture principles whose severity is mandatory

> 102 records

This index as JSON: https://banes-lab.com/json/api/facets/architecture/severity/mandatory

## Entries

- [Explicit Boundaries](https://banes-lab.com/records/architecture/explicit-boundaries.md): A design rule that each module declares its public interface and owner, and other modules reach it only through that interface.
- [Dependency Graph](https://banes-lab.com/records/architecture/dependency-graph.md): Descriptive data about which modules, tasks or services depend on which, extracted as a directed graph.
- [Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md): A design rule that every boundary declares the shape and meaning of what crosses it in a typed contract.
- [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md): The degree to which a public interface keeps its signatures and meaning across releases.
- [API Contract](https://banes-lab.com/records/architecture/api-contract.md): A rule or precondition that each endpoint declares its request, response and error shapes in a versioned schema.
- [Service Contract](https://banes-lab.com/records/architecture/service-contract.md): A rule or precondition that a service declares its operations, their results and their side effects to every consumer.
- [Data Contract](https://banes-lab.com/records/architecture/data-contract.md): A rule or precondition that data exchanged between parties has declared fields, types, nullability and meaning.
- [Schema Contract](https://banes-lab.com/records/architecture/schema-contract.md): A rule or precondition that every payload is validated against a machine-readable schema at the boundary it crosses.
- [Semantic Contracts](https://banes-lab.com/records/architecture/semantic-contracts.md): A rule or precondition that each term and value at a boundary has one agreed meaning, beyond its type.
- [Preconditions](https://banes-lab.com/records/architecture/preconditions.md): A rule or precondition that must hold on an operation's input and state before the operation runs.
- [Invariant](https://banes-lab.com/records/architecture/invariant.md): A rule or precondition that holds for an entity or aggregate in every state it can reach.
- [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md): A rule or precondition that a new version keeps working for consumers written against an older one.
- [Versioning](https://banes-lab.com/records/architecture/versioning.md): A mechanism that labels each release of an interface or schema, so consumers can tell compatible changes from breaking ones.
- [Protocol Compatibility](https://banes-lab.com/records/architecture/protocol-compatibility.md): A rule or precondition that both ends of a connection speak a declared protocol version they both support.
- [Interoperability](https://banes-lab.com/records/architecture/interoperability.md): The degree to which separate systems exchange data and use it correctly through shared formats and contracts.
- [Repeatability](https://banes-lab.com/records/architecture/repeatability.md): The degree to which rerunning the same test or process in the same environment gives the same result.
- [Correctness](https://banes-lab.com/records/architecture/correctness.md): The degree to which the behavior of code matches its specification.
- [Static Analysis](https://banes-lab.com/records/architecture/static-analysis.md): A mechanism that checks source code against a ruleset without running it.
- [Testability](https://banes-lab.com/records/architecture/testability.md): The degree to which code can be tested in isolation, with its dependencies, time and randomness supplied by the test.
- [Validation](https://banes-lab.com/records/architecture/validation.md): The activity of checking that inputs and delivered behavior meet the acceptance criteria of their users.
- [Verification](https://banes-lab.com/records/architecture/verification.md): The activity of checking that an implementation conforms to its specification.
- [Configuration Externalization](https://banes-lab.com/records/architecture/configuration-externalization.md): A design rule that environment-specific values are read from validated external configuration at startup.
- [Single Responsibility Principle (SRP)](https://banes-lab.com/records/architecture/single-responsibility.md): A design rule that a class or module has one reason to change, because it serves one responsibility.
- [Separation of Concerns](https://banes-lab.com/records/architecture/separation-of-concerns.md): A design rule that parsing, business logic, persistence and presentation each live in their own part of the code.
- [Do Not Repeat Yourself (DRY)](https://banes-lab.com/records/architecture/duplicate-code.md): A design rule that each piece of logic, constant or schema has one source in the code, and every other use refers to it.
- [High Cohesion](https://banes-lab.com/records/architecture/high-cohesion.md): The degree to which the members of a class or module work on the same data towards the same purpose.
- [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md): The degree to which a module can change without forcing changes in the modules around it.
- [Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md): A design rule that an object's state is changed only through its own operations, which keep its invariants.
- [Information Hiding](https://banes-lab.com/records/architecture/information-hiding.md): A design rule that a module exposes an interface and keeps the implementation decisions behind it private.
- [Abstraction](https://banes-lab.com/records/architecture/abstraction.md): A design rule that a concept is expressed by what it does for the code that uses it, and the detail of how it does it stays out of that expression.
- [Modularity](https://banes-lab.com/records/architecture/modularity.md): A design rule that a system is divided into cohesive modules with explicit boundaries and few dependencies between them.
- [Interface Segregation Principle (ISP)](https://banes-lab.com/records/architecture/interface-segregation.md): A design rule that a client depends on an interface holding only the methods it uses.
- [Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md): A design rule that high-level policy and low-level detail both depend on an abstraction owned by the policy.
- [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md): A design rule that a subtype can replace its base type anywhere, because it keeps the base type's preconditions, postconditions and invariants.
- [Defensive Programming](https://banes-lab.com/records/architecture/defensive-programming.md): A design rule that code checks its inputs and assumptions before acting on them, and reports a violation as an explicit error.
- [Fail Safe](https://banes-lab.com/records/architecture/fail-safe.md): A design rule that a failing operation leaves the system in the state that causes the least harm.
- [Fail Secure](https://banes-lab.com/records/architecture/fail-secure.md): A design rule that an authentication or policy failure denies access.
- [Error Handling](https://banes-lab.com/records/architecture/error-handling.md): A design rule that every error is either handled with its context kept, or propagated as a typed error the caller must handle.
- [Timeout Pattern](https://banes-lab.com/records/architecture/timeout-pattern.md): A design pattern that gives every external call a time budget and fails the call when the budget runs out.
- [Code Review](https://banes-lab.com/records/architecture/code-review.md): The activity of having a second party read a code change against review standards before it merges.
- [Architectural Consistency](https://banes-lab.com/records/architecture/architectural-consistency.md): The degree to which the code follows the system's declared boundaries, layers and dependency rules.
- [Model Evaluation](https://banes-lab.com/records/architecture/model-evaluation.md): The activity of measuring a model against datasets, metrics and slices, and comparing the results with acceptance thresholds.
- [Logging](https://banes-lab.com/records/architecture/logging.md): A mechanism that records structured events with their context as the code runs.
- [Monitoring](https://banes-lab.com/records/architecture/monitoring.md): A mechanism that collects metrics about resources and service levels over time and compares them with thresholds.
- [Alerting](https://banes-lab.com/records/architecture/alerting.md): A mechanism that notifies an on-call responder when a monitored condition holds for longer than its threshold.
- [Traceability](https://banes-lab.com/records/architecture/traceability.md): The degree to which a request, workflow or change can be followed end to end through correlated records.
- [Adapter Pattern](https://banes-lab.com/records/architecture/adapter-pattern.md): A design pattern that wraps a component with an incompatible interface so it implements the interface its callers expect.
- [Rollback](https://banes-lab.com/records/architecture/rollback.md): A mechanism that restores the previous versioned release when a deployment fails its verification.
- [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md): A mechanism that parses incoming data against a schema at the boundary and rejects any payload that does not conform.
- [Type Safety](https://banes-lab.com/records/architecture/type-safety.md): A mechanism that has the compiler reject operations on values of the wrong type before the code runs.
- [Single Source of Truth](https://banes-lab.com/records/architecture/single-source-of-truth.md): A design rule that each fact, rule or configuration value has one owning definition, and every other value is derived from it.
- [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md): The degree to which one name carries one meaning across the code, the schemas and the documentation.
- [Security by Design](https://banes-lab.com/records/architecture/security-by-design.md): A design rule that threats are modeled and controls built into every component from its first design.
- [Defense in Depth](https://banes-lab.com/records/architecture/defense-in-depth.md): A design rule that several independent security controls protect each asset, so one failed control does not expose it.
- [Least Privilege](https://banes-lab.com/records/architecture/least-privilege.md): A design rule that each user, service and process holds only the permissions its task needs.
- [Secure by Default](https://banes-lab.com/records/architecture/secure-by-default.md): A design rule that every setting ships in its most restrictive safe state, and weakening one requires an explicit opt-in.
- [Attack Surface Reduction](https://banes-lab.com/records/architecture/attack-surface-reduction.md): A design rule that endpoints, ports, features and permissions nothing uses are removed or disabled.
- [Authentication](https://banes-lab.com/records/architecture/authentication.md): A mechanism that verifies a caller's claimed identity from a credential before any protected action runs.
- [Authorization](https://banes-lab.com/records/architecture/authorization.md): A mechanism that decides, from a policy, whether an authenticated principal may perform an action on a resource.
- [Access Control](https://banes-lab.com/records/architecture/access-control.md): A mechanism that evaluates an access policy for each request to a resource and denies the request when the policy does not allow it.
- [Input Validation](https://banes-lab.com/records/architecture/input-validation.md): A mechanism that checks external input against a schema at the boundary before core logic uses it.
- [Output Encoding](https://banes-lab.com/records/architecture/output-encoding.md): A mechanism that escapes values for the context they are written into, such as HTML, SQL or a shell.
- [Encryption in Transit](https://banes-lab.com/records/architecture/encryption-in-transit.md): A mechanism that encrypts traffic between parties with TLS or mutual TLS and verifies the peer's certificate.
- [Secrets Management](https://banes-lab.com/records/architecture/secrets-management.md): The practice of keeping credentials in a secret store, reading them at runtime and rotating them on a schedule.
- [Policy Enforcement](https://banes-lab.com/records/architecture/policy-enforcement.md): A mechanism that blocks an action a policy forbids at the point the action is attempted.
- [Parameterized Queries](https://banes-lab.com/records/architecture/parameterized-queries.md): A mechanism that sends query text and values to the database separately, so values are never parsed as query syntax.
- [Stated Invariant](https://banes-lab.com/records/architecture/stated-invariant.md): A design rule that an invariant a topology relies on is written with its property in a form that could be false, the set it ranges over, the parties it binds and the thing that would object if it stopped holding.
- [Derived Record State](https://banes-lab.com/records/architecture/derived-record-state.md): A design rule that a record's state is a query over the edges it carries, open while its satisfying artifact is unresolved, blocked while a blocker is open and absorbed once the artifact exists, so no party writes a state.
- [Declared Subject](https://banes-lab.com/records/architecture/declared-subject.md): A rule or precondition that a record carries an allocated id and a declared subject key as two fields, so a moved surface keeps the id, a renamed subject keeps the key, and two records sharing a key are a finding.
- [Operand-Free Outcome Surface](https://banes-lab.com/records/architecture/operand-free-outcome-surface.md): A rule or precondition that a surface carrying one jointly authored product declares that one writer per record has no operand there, and settles a collision by announcement and by each author cutting its own duplicate.
- [Projection Channel](https://banes-lab.com/records/architecture/projection-channel.md): A rule or precondition that the projection a host injects into every bounded reader is refreshed in the same change as the fact it carries, in a shape a check reads.
- [Two-Direction Index](https://banes-lab.com/records/architecture/two-direction-index.md): A mechanism that generates an index from the directory on every run and checks it both ways, reporting an entry with no file and a file with no entry, with every scan independent of depth.
- [Independent Lifetime Axes](https://banes-lab.com/records/architecture/independent-lifetime-axes.md): A design rule that a surface's lifetime is declared on three independent axes, retention, mutability and removal authority, each taking a value from a closed set, so no single word stands for all three.
- [Write Scope and Read Population](https://banes-lab.com/records/architecture/write-scope-and-read-population.md): A design rule that a run declares the paths it writes and publishes the set it read as two declarations, because collision is decided by the first and a published result's validity by the second.
- [Single Aggregate](https://banes-lab.com/records/architecture/single-aggregate.md): A rule or precondition that a shared measurement keeps one aggregate, overwritten by each run that can honestly replace it, while a run that cannot streams its verdict instead of writing a second report.
- [Closed Vocabulary](https://banes-lab.com/records/architecture/closed-vocabulary.md): A design rule that every word in a name slot comes from a declared list, and a new word enters the list only by an approved edit.
- [Positional Slot Resolution](https://banes-lab.com/records/architecture/positional-slot-resolution.md): A mechanism that reads each word of a path by the slot it lands in, so the last dot-segment before a file's extension is always its concern and a folder named after a concern tag resolves as the latest role its depth can legally take.
- [Concern-Folder Correspondence](https://banes-lab.com/records/architecture/concern-folder-correspondence.md): A rule or precondition that a file's concern tag matches the label of the folder that holds it.
- [Glob-Resolvable Tree](https://banes-lab.com/records/architecture/glob-resolvable-tree.md): A mechanism that lets one unanchored pattern per concern collect every matching file or folder, at whatever depth it sits.
- [Declared Jurisdiction](https://banes-lab.com/records/architecture/declared-jurisdiction.md): A design rule that a naming gate reads from one declaration the roots it governs, the containers and buckets under each, the classes of file exempt from the grammar, and the trees another system authors or resolves by name, which are exempted once and never governed.
- [Bounded Nesting Depth](https://banes-lab.com/records/architecture/bounded-nesting-depth.md): A rule or precondition that a file sits within a fixed number of folders below its governed root, with each folder taking a later role than the one above it.
- [Sideways Overflow](https://banes-lab.com/records/architecture/sideways-overflow.md): A design pattern that resolves a naming collision with the filename's variant slot and resolves breadth with a sibling subject folder.
- [One Concern Per File](https://banes-lab.com/records/architecture/one-concern-per-file.md): A design rule that each file plays exactly one declared role, and a file that plays two is split.
- [Narrowest Concern](https://banes-lab.com/records/architecture/narrowest-concern.md): A design rule that a file is classified under the narrowest declared role that describes it accurately.
- [Agnostic-First Vocabulary](https://banes-lab.com/records/architecture/agnostic-first-vocabulary.md): A design rule that a domain-specific role word is admitted only where no domain-neutral role already covers it.
- [Guided Vocabulary Refusal](https://banes-lab.com/records/architecture/guided-vocabulary-refusal.md): A mechanism that answers a refused word with the declared word that covers its role, looked up in an indexed rejection table.
- [Derived Naming Registry](https://banes-lab.com/records/architecture/derived-naming-registry.md): Descriptive data about the declared vocabulary and roots, derived from the naming document so a gate can read it, with the reasoning kept in the document.
- [Set-Relative Member Name](https://banes-lab.com/records/architecture/set-relative-member-name.md): A rule or precondition that a file inside a subject folder names only its own subject, because the folder already names the set.
- [Manual Identity Migration](https://banes-lab.com/records/architecture/manual-identity-migration.md): A technique for renaming files one container at a time by hand, re-pointing each pattern and comparing what each aggregator collects before and after.
- [Collision Consolidation](https://banes-lab.com/records/architecture/collision-consolidation.md): A design rule that a filename already held by another file is first read as a sign that both files do the same job, and a variant is added only after the code shows that their jobs differ.
- [Mirrored Test Placement](https://banes-lab.com/records/architecture/mirrored-test-placement.md): A rule or precondition that a test sits in the concern folder of the file it tests, under a test root mirroring that file's governed root, and moves whenever that file moves.
- [Sanctioned Generic Subject](https://banes-lab.com/records/architecture/sanctioned-generic-subject.md): A rule or precondition that a file takes the one generic subject only when it is generic over its type parameters and names no domain noun anywhere in its source.
- [Conformance at Creation](https://banes-lab.com/records/architecture/conformance-at-creation.md): A design rule that a file created under a governed root is named and placed correctly when it is first written, so no conversion queue accumulates behind new work.
- [Registry-Held Order](https://banes-lab.com/records/architecture/registry-held-order.md): A design rule that load or execution order is held by an import list or a registry, so a filename carries no numeric prefix the grammar would have to parse.
- [Externally Resolved Slot](https://banes-lab.com/records/architecture/externally-resolved-slot.md): A mechanism that resolves a name slot whose words another source owns against that source, whether an index that allocates identities, an upstream key set or a field the file itself carries, so the closed vocabulary never holds a copy of them.
- [Root Spine Files](https://banes-lab.com/records/architecture/root-spine-files.md): A rule or precondition that a governed root carries only its entry document and its accumulators at the root, and every other file sits in a concern folder.
- [Idempotency](https://banes-lab.com/records/architecture/idempotency.md): A design rule that repeating an operation with the same input has the same effect as running it once.
- [Atomicity](https://banes-lab.com/records/architecture/atomicity.md): A design rule that the steps of a state change either all take effect or none do.
- [Transaction Boundary](https://banes-lab.com/records/architecture/transaction-boundary.md): A rule or precondition that a transaction covers exactly the writes of one unit of work inside one service.
- [Consistency](https://banes-lab.com/records/architecture/consistency.md): The degree to which stored data satisfies its invariants after every change.
- [Concurrency Control](https://banes-lab.com/records/architecture/concurrency-control.md): A mechanism that coordinates concurrent access to shared state, through locks, versions or compare-and-swap.
- [State Isolation](https://banes-lab.com/records/architecture/state-isolation.md): A design rule that each piece of mutable state belongs to one unit of concurrent execution, so no two units that run at the same time can write it.