# Contracts / Interfaces / Compatibility

> Every principle in this category is listed as a record.

Page: Ontology · Principles
Canonical: https://banes-lab.com/ontology#architecture-category-contracts-interfaces-compatibility

Listed in [Ontology · Principles](https://banes-lab.com/api/pages/ontology/principles.md), after [Causality / Ordering / Distributed Time](https://banes-lab.com/ontology/principles/architecture-category-causality-ordering-distributed-time.md) and before [Control / Coordination / Centralization](https://banes-lab.com/ontology/principles/architecture-category-control-coordination-centralization.md).

Every principle in this category is listed as a record. Each record carries its kind, its severity, the scopes it applies at and the layer it lives in, then the edge relations that join it to other records, the records that point back at it, the contracts that answer to it and the tensions it takes part in. The descriptors say how it is violated, detected, measured, repaired and enforced. Where the record carries one, an exemplar shows the shape before and after the principle is applied.

Relations diagram

The relations inside this category.

```mermaid
flowchart LR
n_design_by_contract["Design by Contract"]
n_explicit_contracts["Explicit Contracts"]
n_stable_interfaces["Stable Interfaces"]
n_interface_based_design["Interface-Based Design"]
n_contract_first_design["Contract-First Design"]
n_api_contract["API Contract"]
n_service_contract["Service Contract"]
n_data_contract["Data Contract"]
n_schema_contract["Schema Contract"]
n_semantic_contracts["Semantic Contracts"]
n_preconditions["Preconditions"]
n_postconditions["Postconditions"]
n_invariant["Invariant"]
n_backward_compatibility["Backward Compatibility"]
n_forward_compatibility["Forward Compatibility"]
n_versioning["Versioning"]
n_protocol_compatibility["Protocol Compatibility"]
n_interoperability["Interoperability"]
n_uniform_interface["Uniform Interface"]
n_consumer_driven_contracts["Consumer-Driven Contracts"]
n_design_by_contract --> n_preconditions
n_design_by_contract --> n_postconditions
n_design_by_contract --> n_invariant
n_explicit_contracts --> n_stable_interfaces
n_explicit_contracts --> n_interoperability
n_explicit_contracts --> n_contract_first_design
n_stable_interfaces --> n_versioning
n_stable_interfaces --> n_backward_compatibility
n_interface_based_design --> n_stable_interfaces
n_contract_first_design --> n_explicit_contracts
n_contract_first_design --> n_schema_contract
n_contract_first_design --> n_interoperability
n_contract_first_design --> n_backward_compatibility
n_api_contract --> n_versioning
n_api_contract --> n_stable_interfaces
n_api_contract --> n_interoperability
n_service_contract --> n_api_contract
n_data_contract --> n_interoperability
n_schema_contract --> n_data_contract
n_preconditions --> n_design_by_contract
n_postconditions --> n_invariant
n_backward_compatibility --> n_versioning
n_backward_compatibility --> n_stable_interfaces
n_versioning --> n_stable_interfaces
n_versioning --> n_backward_compatibility
n_protocol_compatibility --> n_versioning
n_protocol_compatibility --> n_interoperability
n_consumer_driven_contracts --> n_explicit_contracts
n_consumer_driven_contracts --> n_backward_compatibility
n_consumer_driven_contracts --> n_contract_first_design
```

### Design by Contract

- Kind: [principle](https://banes-lab.com/records/kind/principle.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: API, function, class, service
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A design rule that every operation states the preconditions it needs, the postconditions it guarantees and the invariants it keeps.

Requires
[Preconditions](https://banes-lab.com/records/architecture/preconditions.md), [Postconditions](https://banes-lab.com/records/architecture/postconditions.md), [Invariant](https://banes-lab.com/records/architecture/invariant.md)

Reinforces
[Correctness](https://banes-lab.com/records/architecture/correctness.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md)

Enables
[Contract Testing](https://banes-lab.com/records/lexicon/contract-testing.md), [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md)

In tension with
[Development Speed](https://banes-lab.com/records/lexicon/development-speed.md)

Conflicts with
[Implicit Behavior](https://banes-lab.com/records/lexicon/implicit-behavior.md)

Referenced by
[Preconditions](https://banes-lab.com/records/architecture/preconditions.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md)

Contracts
[Architectural Contract Algebra](https://banes-lab.com/records/algorithms/architectural-contract-algebra.md), [Contract-Based Verification Kernel](https://banes-lab.com/records/algorithms/contract-based-verification-kernel.md)

Tensions
[Design by Contract / Development Speed](https://banes-lab.com/records/tension/design-by-contract-development-speed.md)

Distinct from
[Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md): Design by contract states each operation's conditions, while Liskov substitution requires a subtype to keep the conditions of its base type.

Violated by
undocumented assumptions, unchecked inputs

Detected by
missing assertions, missing validation, vague public APIs

Measured by
contract coverage

Refactored by
Add Preconditions, Add Postconditions, Add Invariants

Enforced by
assertions, contract tests, [static analysis](https://banes-lab.com/records/reasoning/technique-static-analysis.md)

Refused by rules
design-by-contract

Before

```typescript
function divideFoo(total: number, count: number) {
return total / count;
}
```

After

```typescript
function divideFoo(total: number, count: number): number {
if (!Number.isFinite(total)) throw new Error("pre: total must be finite");
if (!Number.isInteger(count) || count <= 0) throw new Error("pre: count must be positive");
const result = total / count;
if (!Number.isFinite(result)) throw new Error("post: result must be finite");
return result;
}
```

How it is checked

Checked by
assertions, contract tests, static analysis

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Preconditions](https://banes-lab.com/records/architecture/preconditions.md), [Postconditions](https://banes-lab.com/records/architecture/postconditions.md), [Invariant](https://banes-lab.com/records/architecture/invariant.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md), [Contract Testing](https://banes-lab.com/records/lexicon/contract-testing.md), [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md)

Shape it refuses
[Implicit Behavior](https://banes-lab.com/records/lexicon/implicit-behavior.md)

### Explicit Contracts

- Kind: [principle](https://banes-lab.com/records/kind/principle.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: API, service, data, protocol
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A design rule that every boundary declares the shape and meaning of what crosses it in a typed contract.

Requires
[Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Type Safety](https://banes-lab.com/records/architecture/type-safety.md)

Reinforces
[Predictability](https://banes-lab.com/records/architecture/predictability.md), [Interoperability](https://banes-lab.com/records/architecture/interoperability.md)

Enables
[Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md)

In tension with
[Rapid Prototyping](https://banes-lab.com/records/lexicon/rapid-prototyping.md)

Conflicts with
[Implicit Contract](https://banes-lab.com/records/architecture/implicit-contract.md)

Referenced by
[Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md), [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md), [Autonomy](https://banes-lab.com/records/architecture/autonomy.md)

Contracts
[Contracts Core](https://banes-lab.com/records/algorithms/contracts-core.md), [PAG Authoring Kernel](https://banes-lab.com/records/algorithms/pag-authoring-kernel.md)

Tensions
[Explicit Contracts / Rapid Prototyping](https://banes-lab.com/records/tension/explicit-contracts-rapid-prototyping.md)

Distinct from
[Determinism](https://banes-lab.com/records/architecture/determinism.md): Explicit contracts declare what crosses a boundary, while determinism makes the same inputs give the same result.

Distinct from
[Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md): Explicit contracts require a declared contract, while contract-first design fixes when it is written, before the implementation.

Distinct from
[Independence](https://banes-lab.com/records/architecture/independence.md): Explicit contracts declare boundaries, while independence lets a module be tested and deployed without its neighbors.

Violated by
untyped boundaries, undocumented payloads

Detected by
public methods without DTO/schema, dynamic maps at boundaries

Measured by
boundary contract coverage

Refactored by
Add DTO, Add Schema, Add Interface

Enforced by
[schema validation](https://banes-lab.com/records/architecture/schema-validation.md), API linting

Before

```typescript
function saveFoo(foo: any): any { return fooStore.save(foo); }
```

After

```typescript
interface SaveFoo {
execute(input: Readonly<{ id: FooId; name: string }>): Promise<{ saved: true; version: number }>;
}
const saveFoo: SaveFoo = { execute: input => fooStore.save(input) };
```

How it is checked

Checked by
schema validation, API linting

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Type Safety](https://banes-lab.com/records/architecture/type-safety.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md), [Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md)

Shape it refuses
[Implicit Contract](https://banes-lab.com/records/architecture/implicit-contract.md), [Implicit Contract](https://banes-lab.com/records/architecture/implicit-contract.md)

### Stable Interfaces

- Kind: [quality-attribute](https://banes-lab.com/records/kind/quality-attribute.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: API, module, service
- Aliases: Stable Interface
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
The degree to which a public interface keeps its signatures and meaning across releases.

Requires
[Versioning](https://banes-lab.com/records/architecture/versioning.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md)

Reinforces
[Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md), [Replaceability](https://banes-lab.com/records/architecture/replaceability.md)

Enables
[Independent Consumers](https://banes-lab.com/records/lexicon/independent-consumers.md)

In tension with
[Evolution Speed](https://banes-lab.com/records/lexicon/evolution-speed.md)

Conflicts with
[Breaking Changes](https://banes-lab.com/records/lexicon/breaking-changes.md)

Referenced by
[Explicit Boundaries](https://banes-lab.com/records/architecture/explicit-boundaries.md), [Runtime Extensibility](https://banes-lab.com/records/architecture/runtime-extensibility.md), [Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md), [Interface-Based Design](https://banes-lab.com/records/architecture/interface-based-design.md), [API Contract](https://banes-lab.com/records/architecture/api-contract.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Versioning](https://banes-lab.com/records/architecture/versioning.md), [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md), [Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md), [Composability](https://banes-lab.com/records/architecture/composability.md), [Replaceability](https://banes-lab.com/records/architecture/replaceability.md), [Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md), [Plugin Architecture](https://banes-lab.com/records/architecture/plugin-architecture.md), [Extension Points](https://banes-lab.com/records/architecture/extension-points.md), [Principle of Least Surprise](https://banes-lab.com/records/architecture/principle-of-least-surprise.md)

Tensions
[Stable Interfaces / Evolution Speed](https://banes-lab.com/records/tension/evolution-speed-stable-interfaces.md)

Violated by
signature churn, [schema drift](https://banes-lab.com/records/architecture/schema-drift.md)

Detected by
incompatible API diffs

Measured by
breaking-change frequency

Refactored by
Add Version, Add Adapter, Deprecate Gradually

Enforced by
API diff checks, contract tests

Before

```typescript
class FooService {
createFoo(name: string, tags: string[], notify: boolean, source: string) {}
}
```

After

```typescript
type CreateFooRequest = Readonly<{
name: string;
tags: readonly string[];
extensions: Readonly<Record<string, unknown>>;
}>;
interface FooService { create(request: CreateFooRequest): Promise<FooId>; }
```

How it is checked

Checked by
API diff checks, contract tests

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Versioning](https://banes-lab.com/records/architecture/versioning.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md), [Replaceability](https://banes-lab.com/records/architecture/replaceability.md), [Independent Consumers](https://banes-lab.com/records/lexicon/independent-consumers.md)

Shape it refuses
[Breaking Changes](https://banes-lab.com/records/lexicon/breaking-changes.md)

### Interface-Based Design

- Kind: [principle](https://banes-lab.com/records/kind/principle.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: class, module, service
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A design rule that a module depends on interfaces, and the implementation behind each one is supplied from outside.

Requires
[Abstraction](https://banes-lab.com/records/architecture/abstraction.md), [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md)

Reinforces
[Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md), [Testability](https://banes-lab.com/records/architecture/testability.md)

Enables
[Dependency Injection](https://banes-lab.com/records/architecture/dependency-injection.md), [Adapter Pattern](https://banes-lab.com/records/architecture/adapter-pattern.md)

In tension with
[Interface Overuse](https://banes-lab.com/records/lexicon/interface-overuse.md)

Conflicts with
[Concrete Coupling](https://banes-lab.com/records/architecture/concrete-coupling.md)

Referenced by
[Composition Over Inheritance](https://banes-lab.com/records/architecture/composition-over-inheritance.md)

Tensions
[Interface-Based Design / Interface Overuse](https://banes-lab.com/records/tension/interface-based-design-interface-overuse.md)

Distinct from
[Composition Over Inheritance](https://banes-lab.com/records/architecture/composition-over-inheritance.md): Interface-based design depends on interfaces, while composition over inheritance reuses behavior by holding objects rather than extending classes.

Distinct from
[Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md): Interface-based design depends on interfaces supplied from outside, while dependency inversion also fixes that the policy side owns the interface.

Violated by
direct dependency on implementations

Detected by
concrete constructor dependencies

Measured by
interface-to-implementation boundary ratio

Refactored by
Extract Interface, Inject Dependency

Enforced by
dependency rules

Before

```typescript
function processFoo(store: SqlFooStore, foo: Foo) { return store.insert(foo); }
```

After

```typescript
interface FooWriter { save(foo: Foo): Promise<void>; }
function processFoo(store: FooWriter, foo: Foo) { return store.save(foo); }
```

How it is checked

Checked by
dependency rules

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Abstraction](https://banes-lab.com/records/architecture/abstraction.md), [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Dependency Inversion Principle (DIP)](https://banes-lab.com/records/architecture/dependency-inversion.md), [Testability](https://banes-lab.com/records/architecture/testability.md), [Dependency Injection](https://banes-lab.com/records/architecture/dependency-injection.md), [Adapter Pattern](https://banes-lab.com/records/architecture/adapter-pattern.md)

Shape it refuses
[Concrete Coupling](https://banes-lab.com/records/architecture/concrete-coupling.md)

### Contract-First Design

- Kind: [principle](https://banes-lab.com/records/kind/principle.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: API, service, integration
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A design rule that a boundary's contract is written and agreed before the implementation behind it.

Requires
[Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md), [Schema Contract](https://banes-lab.com/records/architecture/schema-contract.md)

Reinforces
[Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md)

Enables
[Consumer-Driven Development](https://banes-lab.com/records/lexicon/consumer-driven-development.md)

In tension with
[Iteration Speed](https://banes-lab.com/records/lexicon/iteration-speed.md)

Conflicts with
[Implementation-First Integration](https://banes-lab.com/records/lexicon/implementation-first-integration.md)

Referenced by
[Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md), [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md)

Tensions
[Contract-First Design / Iteration Speed](https://banes-lab.com/records/tension/contract-first-design-iteration-speed.md)

Violated by
generated contracts from unstable implementation

Detected by
absent contract before implementation

Measured by
contract-first coverage

Refactored by
Define Contract, Generate Stubs, Add Contract Tests

Enforced by
CI contract gates

Before

```typescript
app.post("/foo", async request => fooStore.save(await request.json()));
```

After

```typescript
type CreateFooRequest = { name: string };
type CreateFooResponse = { id: FooId; version: 1 };
interface CreateFooContract {
request: CreateFooRequest;
response: CreateFooResponse;
}
app.post("/foo", implement<CreateFooContract>(createFoo));
```

How it is checked

Checked by
CI contract gates

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md), [Schema Contract](https://banes-lab.com/records/architecture/schema-contract.md), [Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Consumer-Driven Development](https://banes-lab.com/records/lexicon/consumer-driven-development.md)

Shape it refuses
[Implementation-First Integration](https://banes-lab.com/records/lexicon/implementation-first-integration.md)

### API Contract

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: API, service boundary
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that each endpoint declares its request, response and error shapes in a versioned schema.

Requires
[Schema](https://banes-lab.com/records/lexicon/schema.md), [Versioning](https://banes-lab.com/records/architecture/versioning.md), [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md)

Reinforces
[Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md)

Enables
[Client Compatibility](https://banes-lab.com/records/lexicon/client-compatibility.md)

In tension with
[Evolution](https://banes-lab.com/records/lexicon/evolution.md)

Conflicts with
[Breaking API Change](https://banes-lab.com/records/lexicon/breaking-api-change.md)

Referenced by
[Service Contract](https://banes-lab.com/records/architecture/service-contract.md), [Self-Describing API](https://banes-lab.com/records/architecture/self-describing-api.md)

Tensions
[API Contract / Evolution](https://banes-lab.com/records/tension/api-contract-evolution.md)

Distinct from
[Semantic Contract](https://banes-lab.com/records/lexicon/semantic-contract.md): An API contract declares the shapes of requests, responses and errors, while a semantic contract declares what the operations mean.

Violated by
undocumented endpoints, inconsistent status/error formats

Detected by
OpenAPI drift, missing endpoint schemas

Measured by
contract coverage, breaking diff count

Refactored by
Add OpenAPI, Normalize Responses, Version API

Enforced by
OpenAPI linting, contract tests

Before

```typescript
app.get("/foo/:id", async request => fooStore.find(request.params.id));
```

After

```typescript
const getFooApi = endpoint({
method: "GET",
path: "/v1/foo/{id}",
request: FooIdSchema,
response: FooResponseSchema,
errors: ["FOO_NOT_FOUND"] as const,
});
```

How it is checked

Checked by
OpenAPI linting, contract tests

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Schema](https://banes-lab.com/records/lexicon/schema.md), [Versioning](https://banes-lab.com/records/architecture/versioning.md), [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md), [Client Compatibility](https://banes-lab.com/records/lexicon/client-compatibility.md)

Shape it refuses
[Breaking API Change](https://banes-lab.com/records/lexicon/breaking-api-change.md)

### Service Contract

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: service, integration
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that a service declares its operations, their results and their side effects to every consumer.

Requires
[API Contract](https://banes-lab.com/records/architecture/api-contract.md), [Semantic Contract](https://banes-lab.com/records/lexicon/semantic-contract.md)

Reinforces
[Autonomy](https://banes-lab.com/records/architecture/autonomy.md), [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md)

Enables
[Independent Deployment](https://banes-lab.com/records/lexicon/independent-deployment.md)

In tension with
[Distributed Evolution](https://banes-lab.com/records/lexicon/distributed-evolution.md)

Conflicts with
[Hidden Service Coupling](https://banes-lab.com/records/lexicon/hidden-service-coupling.md)

Referenced by
[Service-Oriented Architecture](https://banes-lab.com/records/architecture/service-oriented-architecture.md)

Tensions
[Service Contract / Distributed Evolution](https://banes-lab.com/records/tension/distributed-evolution-service-contract.md)

Distinct from
[API Contract](https://banes-lab.com/records/architecture/api-contract.md): A service contract declares a service's operations, results and side effects, while an API contract declares the shapes at each endpoint.

Distinct from
[Semantic Contract](https://banes-lab.com/records/lexicon/semantic-contract.md): A service contract covers one service's whole surface, while a semantic contract is the meaning part of any interface's contract.

Violated by
undocumented side effects, unstable service behavior

Detected by
consumer failures after service changes

Measured by
consumer contract pass rate

Refactored by
Add Consumer Contract, Define SLA, Version Service

Enforced by
contract tests, deployment gates

Before

```typescript
class FooClient {
create(body: any) { return http.post("/foo", body); }
}
```

After

```typescript
interface FooServiceContract {
create(input: CreateFoo): Promise<Result<FooCreated, FooError>>;
}
class FooClient implements FooServiceContract {
create(input: CreateFoo) { return transport.call("Foo.Create", input); }
}
```

How it is checked

Checked by
contract tests, deployment gates

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[API Contract](https://banes-lab.com/records/architecture/api-contract.md), [Semantic Contract](https://banes-lab.com/records/lexicon/semantic-contract.md), [Autonomy](https://banes-lab.com/records/architecture/autonomy.md), [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md), [Independent Deployment](https://banes-lab.com/records/lexicon/independent-deployment.md)

Shape it refuses
[Hidden Service Coupling](https://banes-lab.com/records/lexicon/hidden-service-coupling.md)

### Data Contract

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: data, message, persistence, integration
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that data exchanged between parties has declared fields, types, nullability and meaning.

Requires
[Schema](https://banes-lab.com/records/lexicon/schema.md), [Type Safety](https://banes-lab.com/records/architecture/type-safety.md), [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md)

Reinforces
[Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Data Quality](https://banes-lab.com/records/lexicon/data-quality.md)

Enables
[Schema Evolution](https://banes-lab.com/records/lexicon/schema-evolution.md)

In tension with
[Flexible Ingestion](https://banes-lab.com/records/lexicon/flexible-ingestion.md)

Conflicts with
[Schema Drift](https://banes-lab.com/records/architecture/schema-drift.md)

Referenced by
[Schema Contract](https://banes-lab.com/records/architecture/schema-contract.md), [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md), [Canonical Data Model](https://banes-lab.com/records/architecture/canonical-data-model.md)

Tensions
[Data Contract / Flexible Ingestion](https://banes-lab.com/records/tension/data-contract-flexible-ingestion.md)

Violated by
untyped maps, implicit fields, undocumented nullability

Detected by
data validation failures, schema mismatch

Measured by
schema conformance rate

Refactored by
Add DTO, Add Schema, Normalize Field Semantics

Enforced by
schema registry, validation gates

Before

```typescript
type FooMessage = Record<string, unknown>;
queue.publish("foo", payload);
```

After

```typescript
type FooMessageV1 = Readonly<{
type: "FooCreated";
version: 1;
fooId: FooId;
name: string;
}>;
queue.publish<FooMessageV1>("foo.created.v1", message);
```

How it is checked

Checked by
schema registry, validation gates

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Schema](https://banes-lab.com/records/lexicon/schema.md), [Type Safety](https://banes-lab.com/records/architecture/type-safety.md), [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md), [Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Data Quality](https://banes-lab.com/records/lexicon/data-quality.md), [Schema Evolution](https://banes-lab.com/records/lexicon/schema-evolution.md)

Shape it refuses
[Schema Drift](https://banes-lab.com/records/architecture/schema-drift.md)

### Schema Contract

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: data, API, message
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that every payload is validated against a machine-readable schema at the boundary it crosses.

Requires
[Canonical Schema](https://banes-lab.com/records/architecture/canonical-schema.md), [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md)

Reinforces
[Data Contract](https://banes-lab.com/records/architecture/data-contract.md), [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md)

Enables
[Automated Validation](https://banes-lab.com/records/lexicon/automated-validation.md)

In tension with
[Schema Flexibility](https://banes-lab.com/records/lexicon/schema-flexibility.md)

Conflicts with
[Ad-Hoc Payloads](https://banes-lab.com/records/lexicon/ad-hoc-payloads.md)

Referenced by
[Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md), [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md), [Canonical Schema](https://banes-lab.com/records/architecture/canonical-schema.md)

Tensions
[Schema Contract / Schema Flexibility](https://banes-lab.com/records/tension/schema-contract-schema-flexibility.md)

Distinct from
[Data Contract](https://banes-lab.com/records/architecture/data-contract.md): A data contract declares the fields, types and meaning of exchanged data, while a schema contract validates each payload against a schema at the boundary.

Violated by
unvalidated payloads, undocumented field changes

Detected by
schema diff failures

Measured by
schema validation coverage

Refactored by
Add JSON Schema, Protobuf, Avro, OpenAPI

Enforced by
schema registry, CI schema checks

Before

```typescript
const foo = JSON.parse(raw) as Foo;
```

After

```typescript
const FooSchema = object({ id: string(), count: integer() });
const foo: Foo = FooSchema.parse(JSON.parse(raw));
```

How it is checked

Checked by
schema registry, CI schema checks

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Canonical Schema](https://banes-lab.com/records/architecture/canonical-schema.md), [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md), [Data Contract](https://banes-lab.com/records/architecture/data-contract.md), [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md), [Automated Validation](https://banes-lab.com/records/lexicon/automated-validation.md)

Shape it refuses
[Ad-Hoc Payloads](https://banes-lab.com/records/lexicon/ad-hoc-payloads.md)

### Semantic Contracts

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: domain, API, data
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that each term and value at a boundary has one agreed meaning, beyond its type.

Requires
[Ubiquitous Language](https://banes-lab.com/records/architecture/ubiquitous-language.md), [Domain Model](https://banes-lab.com/records/architecture/domain-model.md)

Reinforces
[Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md)

Enables
[Reliable Integration](https://banes-lab.com/records/lexicon/reliable-integration.md)

In tension with
[Cross-Domain Translation](https://banes-lab.com/records/lexicon/cross-domain-translation.md)

Conflicts with
[Ambiguous Naming](https://banes-lab.com/records/lexicon/ambiguous-naming.md)

Referenced by
[Domain Model](https://banes-lab.com/records/architecture/domain-model.md), [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md), [Ubiquitous Language](https://banes-lab.com/records/architecture/ubiquitous-language.md)

Tensions
[Semantic Contracts / Cross-Domain Translation](https://banes-lab.com/records/tension/cross-domain-translation-semantic-contracts.md)

Violated by
same term with different meanings

Detected by
conflicting field meanings, overloaded names

Measured by
semantic conflict count

Refactored by
Rename, Introduce Bounded Context, Add Anti-Corruption Layer

Enforced by
domain glossary, contract review

Before

```typescript
function reserveFoo(count: number) { return fooStore.decrement(count); }
```

After

```typescript
type PositiveCount = number & { readonly __brand: "PositiveCount" };
function reserveFoo(count: PositiveCount): Promise<{ reserved: true }> {
return fooInventory.reserveExactly(count);
}
```

How it is checked

Checked by
domain glossary, contract review

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Ubiquitous Language](https://banes-lab.com/records/architecture/ubiquitous-language.md), [Domain Model](https://banes-lab.com/records/architecture/domain-model.md), [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md), [Reliable Integration](https://banes-lab.com/records/lexicon/reliable-integration.md)

Shape it refuses
[Ambiguous Naming](https://banes-lab.com/records/lexicon/ambiguous-naming.md)

### Preconditions

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: function, method, API
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that must hold on an operation's input and state before the operation runs.

Requires
[Input Validation](https://banes-lab.com/records/architecture/input-validation.md)

Reinforces
[Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md), [Fail Fast](https://banes-lab.com/records/architecture/fail-fast.md)

Enables
[Correctness](https://banes-lab.com/records/architecture/correctness.md)

In tension with
[Permissive APIs](https://banes-lab.com/records/lexicon/permissive-apis.md)

Conflicts with
[Implicit Assumptions](https://banes-lab.com/records/lexicon/implicit-assumptions.md)

Referenced by
[Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md), [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md), [Fail Fast](https://banes-lab.com/records/architecture/fail-fast.md)

Tensions
[Preconditions / Permissive APIs](https://banes-lab.com/records/tension/permissive-apis-preconditions.md)

Distinct from
[Invariant](https://banes-lab.com/records/architecture/invariant.md): A precondition holds before one operation runs, while an invariant holds in every reachable state.

Distinct from
[Postconditions](https://banes-lab.com/records/architecture/postconditions.md): A precondition is checked before an operation runs, while a postcondition is guaranteed when it returns.

Violated by
accepting invalid state/input

Detected by
missing validation before state transition

Measured by
invalid-input handling coverage

Refactored by
Add Guard Clause, Add Validator

Enforced by
[validation rules](https://banes-lab.com/records/lexicon/validation-rules.md), [static analysis](https://banes-lab.com/records/reasoning/technique-static-analysis.md)

Before

```typescript
function renameFoo(foo: Foo, name: string) { foo.name = name; }
```

After

```typescript
function renameFoo(foo: Foo, name: string) {
if (foo.status !== "active") throw new Error("pre: Foo must be active");
if (name.trim().length === 0) throw new Error("pre: name required");
foo.rename(name.trim());
}
```

How it is checked

Checked by
validation rules, static analysis

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Input Validation](https://banes-lab.com/records/architecture/input-validation.md), [Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md), [Fail Fast](https://banes-lab.com/records/architecture/fail-fast.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md)

Shape it refuses
[Implicit Assumptions](https://banes-lab.com/records/lexicon/implicit-assumptions.md)

### Postconditions

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: function, method, transaction
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that an operation's result and resulting state must satisfy when it returns.

Requires
[Result Validation](https://banes-lab.com/records/lexicon/result-validation.md), [Invariant](https://banes-lab.com/records/architecture/invariant.md)

Reinforces
[Correctness](https://banes-lab.com/records/architecture/correctness.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md)

Enables
[Testability](https://banes-lab.com/records/architecture/testability.md)

In tension with
[Runtime Cost](https://banes-lab.com/records/lexicon/runtime-cost.md)

Conflicts with
[Undefined Results](https://banes-lab.com/records/lexicon/undefined-results.md)

Referenced by
[Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md), [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md)

Tensions
[Postconditions / Runtime Cost](https://banes-lab.com/records/tension/postconditions-runtime-cost.md)

Distinct from
[Invariant](https://banes-lab.com/records/architecture/invariant.md): A postcondition holds when one operation returns, while an invariant holds in every state an entity can reach.

Violated by
returning invalid output state

Detected by
missing assertions on results

Measured by
property test coverage

Refactored by
Add Assertions, Add Result Type, Add Contract Tests

Enforced by
property tests, invariant checks

Before

```typescript
async function createFoo(foo: Foo) { return fooStore.save(foo); }
```

After

```typescript
async function createFoo(foo: Foo): Promise<FooId> {
await fooStore.save(foo);
const saved = await fooStore.find(foo.id);
if (!saved) throw new Error("post: Foo must be persisted");
return saved.id;
}
```

How it is checked

Checked by
property tests, invariant checks

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Result Validation](https://banes-lab.com/records/lexicon/result-validation.md), [Invariant](https://banes-lab.com/records/architecture/invariant.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md), [Predictability](https://banes-lab.com/records/architecture/predictability.md), [Testability](https://banes-lab.com/records/architecture/testability.md)

Shape it refuses
[Undefined Results](https://banes-lab.com/records/lexicon/undefined-results.md)

### Invariant

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: entity, aggregate, module, system
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that holds for an entity or aggregate in every state it can reach.

Requires
[Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md), [Validation](https://banes-lab.com/records/architecture/validation.md)

Reinforces
[Correctness](https://banes-lab.com/records/architecture/correctness.md), [Consistency](https://banes-lab.com/records/architecture/consistency.md)

Enables
[Safe Refactoring](https://banes-lab.com/records/lexicon/safe-refactoring.md)

In tension with
[Flexibility](https://banes-lab.com/records/lexicon/flexibility.md)

Conflicts with
[External State Mutation](https://banes-lab.com/records/lexicon/external-state-mutation.md)

Referenced by
[Domain Model](https://banes-lab.com/records/architecture/domain-model.md), [Aggregate](https://banes-lab.com/records/architecture/aggregate.md), [Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md), [Postconditions](https://banes-lab.com/records/architecture/postconditions.md), [Liskov Substitution Principle (LSP)](https://banes-lab.com/records/architecture/liskov-substitution.md), [Consistency](https://banes-lab.com/records/architecture/consistency.md)

Tensions
[Invariant / Flexibility](https://banes-lab.com/records/tension/flexibility-invariant.md)

Violated by
invalid domain states, broken aggregate rules

Detected by
mutable public state, missing invariant checks

Measured by
invariant test coverage

Refactored by
Encapsulate State, Add Factory, Add Validation

Enforced by
domain tests, constructors, type system

Before

```typescript
class FooAccount {
balance = 0;
withdraw(amount: number) { this.balance -= amount; }
}
```

After

```typescript
class FooAccount {
#balance = 0;
withdraw(amount: number) {
if (amount <= 0 || amount > this.#balance) throw new Error("invariant: balance >= 0");
this.#balance -= amount;
}
}
```

How it is checked

Checked by
domain tests, constructors, type system

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md), [Validation](https://banes-lab.com/records/architecture/validation.md), [Correctness](https://banes-lab.com/records/architecture/correctness.md), [Consistency](https://banes-lab.com/records/architecture/consistency.md), [Safe Refactoring](https://banes-lab.com/records/lexicon/safe-refactoring.md)

Shape it refuses
[External State Mutation](https://banes-lab.com/records/lexicon/external-state-mutation.md)

### Backward Compatibility

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: API, schema, protocol
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that a new version keeps working for consumers written against an older one.

Requires
[Versioning](https://banes-lab.com/records/architecture/versioning.md), [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md)

Reinforces
[Consumer Safety](https://banes-lab.com/records/lexicon/consumer-safety.md)

Enables
[Incremental Deployment](https://banes-lab.com/records/lexicon/incremental-deployment.md)

In tension with
[Cleanup / Simplification](https://banes-lab.com/records/lexicon/cleanup-simplification.md)

Conflicts with
[Breaking Change](https://banes-lab.com/records/lexicon/breaking-change.md)

Referenced by
[Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md), [Versioning](https://banes-lab.com/records/architecture/versioning.md), [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md), [Declared Jurisdiction](https://banes-lab.com/records/architecture/declared-jurisdiction.md)

Tensions
[Backward Compatibility / Cleanup / Simplification](https://banes-lab.com/records/tension/backward-compatibility-cleanup-simplification.md)

Distinct from
[Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md): Backward compatibility is the property a new version keeps, while consumer-driven contracts are how a provider verifies it against recorded expectations.

Violated by
removing fields, changing semantics, narrowing types

Detected by
API/schema diff

Measured by
breaking-change count

Refactored by
Add Version, Deprecate, Add Adapter

Enforced by
compatibility tests, API diff gates

Before

```typescript
app.get("/foo", () => ({ label: "Foo", tags: [] }));
```

After

```typescript
app.get("/v1/foo", () => ({ name: "Foo" }));
app.get("/v2/foo", () => ({ label: "Foo", tags: [] }));
```

How it is checked

Checked by
compatibility tests, API diff gates

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Versioning](https://banes-lab.com/records/architecture/versioning.md), [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Consumer Safety](https://banes-lab.com/records/lexicon/consumer-safety.md), [Incremental Deployment](https://banes-lab.com/records/lexicon/incremental-deployment.md)

Shape it refuses
[Breaking Change](https://banes-lab.com/records/lexicon/breaking-change.md)

### Forward Compatibility

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: API, schema, protocol
- Aliases: Unknown Field Handling
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that an older reader accepts data from a newer writer by ignoring the fields it does not know rather than failing on them.

Requires
[Extensible Schema](https://banes-lab.com/records/lexicon/extensible-schema.md)

Reinforces
[Evolutionary Architecture](https://banes-lab.com/records/architecture/evolutionary-architecture.md)

Enables
[Rolling Upgrades](https://banes-lab.com/records/lexicon/rolling-upgrades.md)

In tension with
[Strong Validation](https://banes-lab.com/records/lexicon/strong-validation.md)

Conflicts with
[Strict Fragile Parsers](https://banes-lab.com/records/lexicon/strict-fragile-parsers.md)

Tensions
[Forward Compatibility / Strong Validation](https://banes-lab.com/records/tension/forward-compatibility-strong-validation.md)

Distinct from
[Extensible Schema](https://banes-lab.com/records/lexicon/extensible-schema.md): Forward compatibility is the reader tolerating unknown fields, while an extensible schema is the writer's shape that lets fields be added.

Violated by
rejecting unknown safe fields

Detected by
parser failures on additive changes

Measured by
forward-compatibility test pass rate

Refactored by
Add Extension Points, Ignore Unknown Fields Safely

Enforced by
compatibility test matrix

Refused by rules
forward-compatibility

Before

```typescript
function readFoo(input: { name: string }) {
if (Object.keys(input).length !== 1) throw new Error("unknown field");
return input.name;
}
```

After

```typescript
type FooEnvelope = { name: string; extensions?: Record<string, unknown> };
function readFoo(input: FooEnvelope) {
return { name: input.name, extensions: input.extensions ?? {} };
}
```

How it is checked

Checked by
compatibility test matrix

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Extensible Schema](https://banes-lab.com/records/lexicon/extensible-schema.md), [Evolutionary Architecture](https://banes-lab.com/records/architecture/evolutionary-architecture.md), [Rolling Upgrades](https://banes-lab.com/records/lexicon/rolling-upgrades.md)

Shape it refuses
[Strict Fragile Parsers](https://banes-lab.com/records/lexicon/strict-fragile-parsers.md)

### Versioning

- Kind: [mechanism](https://banes-lab.com/records/kind/mechanism.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: API, schema, package, service
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A mechanism that labels each release of an interface or schema, so consumers can tell compatible changes from breaking ones.

Requires
[Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Compatibility Policy](https://banes-lab.com/records/lexicon/compatibility-policy.md)

Reinforces
[Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Governance](https://banes-lab.com/records/architecture/governance.md)

Enables
[Controlled Evolution](https://banes-lab.com/records/lexicon/controlled-evolution.md)

In tension with
[Version Sprawl](https://banes-lab.com/records/lexicon/version-sprawl.md)

Conflicts with
[Silent Breaking Changes](https://banes-lab.com/records/lexicon/silent-breaking-changes.md)

Referenced by
[Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [API Contract](https://banes-lab.com/records/architecture/api-contract.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Protocol Compatibility](https://banes-lab.com/records/architecture/protocol-compatibility.md), [Integration Events](https://banes-lab.com/records/architecture/integration-events.md)

Contracts
[Versioned Evolution Over Breaking Change](https://banes-lab.com/records/algorithms/no-breaking-change.md), [Living Profile Kernel](https://banes-lab.com/records/algorithms/living-profile-kernel.md)

Tensions
[Versioning / Version Sprawl](https://banes-lab.com/records/tension/version-sprawl-versioning.md)

Violated by
unversioned breaking changes

Detected by
incompatible diff without version bump

Measured by
version compliance, deprecation window

Refactored by
Add Semantic Versioning, Add API Version

Enforced by
release gates, API checks

Before

```typescript
queue.publish("foo.created", { id: foo.id, name: foo.name });
```

After

```typescript
queue.publish("foo.created.v2", {
schemaVersion: 2,
id: foo.id,
label: foo.name,
});
```

How it is checked

Checked by
release gates, API checks

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md), [Compatibility Policy](https://banes-lab.com/records/lexicon/compatibility-policy.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Governance](https://banes-lab.com/records/architecture/governance.md), [Controlled Evolution](https://banes-lab.com/records/lexicon/controlled-evolution.md)

Shape it refuses
[Silent Breaking Changes](https://banes-lab.com/records/lexicon/silent-breaking-changes.md)

### Protocol Compatibility

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: integration, network, message
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that both ends of a connection speak a declared protocol version they both support.

Requires
[Protocol Contract](https://banes-lab.com/records/lexicon/protocol-contract.md), [Versioning](https://banes-lab.com/records/architecture/versioning.md)

Reinforces
[Interoperability](https://banes-lab.com/records/architecture/interoperability.md)

Enables
[Multi-Client Integration](https://banes-lab.com/records/lexicon/multi-client-integration.md)

In tension with
[Protocol Optimization](https://banes-lab.com/records/lexicon/protocol-optimization.md)

Conflicts with
[Proprietary Drift](https://banes-lab.com/records/lexicon/proprietary-drift.md)

Tensions
[Protocol Compatibility / Protocol Optimization](https://banes-lab.com/records/tension/protocol-compatibility-protocol-optimization.md)

Distinct from
[Protocol Contract](https://banes-lab.com/records/lexicon/protocol-contract.md): Protocol compatibility is both ends agreeing on a supported version, while the protocol contract is the set of messages and sequences that version defines.

Violated by
unsupported protocol changes

Detected by
protocol conformance failure

Measured by
conformance test pass rate

Refactored by
Add Adapter, Normalize Protocol

Enforced by
conformance tests

Before

```typescript
socket.send(JSON.stringify({ action: "save", foo }));
```

After

```typescript
type FooFrameV1 = { protocol: "foo/1"; type: "save"; payload: Foo };
socket.send(encodeFrame<FooFrameV1>({ protocol: "foo/1", type: "save", payload: foo }));
```

How it is checked

Checked by
conformance tests

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Protocol Contract](https://banes-lab.com/records/lexicon/protocol-contract.md), [Versioning](https://banes-lab.com/records/architecture/versioning.md), [Interoperability](https://banes-lab.com/records/architecture/interoperability.md), [Multi-Client Integration](https://banes-lab.com/records/lexicon/multi-client-integration.md)

Shape it refuses
[Proprietary Drift](https://banes-lab.com/records/lexicon/proprietary-drift.md)

### Interoperability

- Kind: [quality-attribute](https://banes-lab.com/records/kind/quality-attribute.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- Scope: API, data, protocol, system
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
The degree to which separate systems exchange data and use it correctly through shared formats and contracts.

Requires
[Contracts](https://banes-lab.com/records/lexicon/contracts.md), [Standards](https://banes-lab.com/records/lexicon/standards.md), [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md)

Reinforces
[Portability](https://banes-lab.com/records/architecture/portability.md), [Integration](https://banes-lab.com/records/lexicon/integration.md)

Enables
[Cross-System Communication](https://banes-lab.com/records/lexicon/cross-system-communication.md)

In tension with
[Domain-Specific Optimization](https://banes-lab.com/records/lexicon/domain-specific-optimization.md)

Conflicts with
[Proprietary Coupling](https://banes-lab.com/records/lexicon/proprietary-coupling.md)

Referenced by
[Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md), [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md), [API Contract](https://banes-lab.com/records/architecture/api-contract.md), [Data Contract](https://banes-lab.com/records/architecture/data-contract.md), [Protocol Compatibility](https://banes-lab.com/records/architecture/protocol-compatibility.md), [Standards Compliance](https://banes-lab.com/records/architecture/standards-compliance.md), [Integration Events](https://banes-lab.com/records/architecture/integration-events.md), [Robustness Principle](https://banes-lab.com/records/architecture/robustness-principle.md), [Standardization](https://banes-lab.com/records/architecture/standardization.md), [Self-Describing API](https://banes-lab.com/records/architecture/self-describing-api.md), [Adapter Pattern](https://banes-lab.com/records/architecture/adapter-pattern.md), [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md), [Canonical Data Model](https://banes-lab.com/records/architecture/canonical-data-model.md), [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md)

Tensions
[Interoperability / Domain-Specific Optimization](https://banes-lab.com/records/tension/domain-specific-optimization-interoperability.md)

Distinct from
[Portability](https://banes-lab.com/records/architecture/portability.md): Interoperability is systems exchanging data correctly, while portability is software running on another platform unchanged.

Distinct from
[Compatibility](https://banes-lab.com/records/lexicon/compatibility.md): Interoperability is exchange through shared formats and contracts, while compatibility is working across versions without modification.

Distinct from
[Data Quality](https://banes-lab.com/records/lexicon/data-quality.md): Interoperability is exchange between systems, while data quality is the accuracy and completeness of the data exchanged.

Distinct from
[Domain-Specific Optimization](https://banes-lab.com/records/lexicon/domain-specific-optimization.md): Interoperability is broad exchange, while domain-specific optimization is the tuning for one domain it trades against.

Distinct from
[Integration](https://banes-lab.com/records/lexicon/integration.md): Interoperability is the ability to exchange data correctly, while integration is the degree systems are actually connected into one whole.

Distinct from
[Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md): Interoperability spans separate systems, while semantic consistency is one name keeping one meaning inside a system.

Distinct from
[Discoverability](https://banes-lab.com/records/lexicon/discoverability.md): Interoperability is exchanging data correctly, while discoverability is how easily a component's capabilities are found.

Violated by
incompatible formats, hidden assumptions

Detected by
integration test failures

Measured by
interoperability test coverage

Refactored by
Standardize Format, Add Adapter, Add Schema

Enforced by
contract tests, standards checks

Before

```typescript
fooClient.send(serializeWithPrivateFormat(foo));
```

After

```typescript
const payload: JsonFooV1 = toJsonFooV1(foo);
fooClient.send(JSON.stringify(payload), { contentType: "application/json" });
```

How it is checked

Checked by
contract tests, standards checks

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Contracts](https://banes-lab.com/records/lexicon/contracts.md), [Standards](https://banes-lab.com/records/lexicon/standards.md), [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md), [Portability](https://banes-lab.com/records/architecture/portability.md), [Integration](https://banes-lab.com/records/lexicon/integration.md), [Cross-System Communication](https://banes-lab.com/records/lexicon/cross-system-communication.md)

Shape it refuses
[Proprietary Coupling](https://banes-lab.com/records/lexicon/proprietary-coupling.md)

### Uniform Interface

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: API, resource boundary
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that every resource in an API uses the same verbs, response shapes and error format.

Requires
[Consistent Semantics](https://banes-lab.com/records/lexicon/consistent-semantics.md), [Stable Contracts](https://banes-lab.com/records/lexicon/stable-contracts.md)

Reinforces
[Principle of Least Surprise](https://banes-lab.com/records/architecture/principle-of-least-surprise.md)

Enables
[API Usability](https://banes-lab.com/records/lexicon/api-usability.md)

In tension with
[Specialized Endpoints](https://banes-lab.com/records/lexicon/specialized-endpoints.md)

Conflicts with
[Ad-Hoc Endpoints](https://banes-lab.com/records/lexicon/ad-hoc-endpoints.md), [Chatty Interface](https://banes-lab.com/records/architecture/chatty-interface.md)

Referenced by
[Composite Pattern](https://banes-lab.com/records/architecture/composite-pattern.md)

Tensions
[Uniform Interface / Specialized Endpoints](https://banes-lab.com/records/tension/specialized-endpoints-uniform-interface.md)

Distinct from
[Consistent Semantics](https://banes-lab.com/records/lexicon/consistent-semantics.md): A uniform interface fixes the same verbs, shapes and error format across resources, while consistent semantics fixes that an operation means the same thing everywhere.

Distinct from
[Stable Contracts](https://banes-lab.com/records/lexicon/stable-contracts.md): A uniform interface is sameness across resources, while stable contracts are sameness over time.

Violated by
inconsistent verbs, response shapes, error formats

Detected by
API lint violations

Measured by
endpoint consistency score

Refactored by
Normalize API, Standardize Error Model

Enforced by
API style guide, OpenAPI linting

Before

```typescript
fooApi.createFoo(foo);
barApi.post("/bar", bar);
bazApi.execute("DELETE_BAZ", baz.id);
```

After

```typescript
resourceClient.post("/foos", foo);
resourceClient.post("/bars", bar);
resourceClient.delete(`/bazes/${baz.id}`);
```

How it is checked

Checked by
API style guide, OpenAPI linting

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Consistent Semantics](https://banes-lab.com/records/lexicon/consistent-semantics.md), [Stable Contracts](https://banes-lab.com/records/lexicon/stable-contracts.md), [Principle of Least Surprise](https://banes-lab.com/records/architecture/principle-of-least-surprise.md), [API Usability](https://banes-lab.com/records/lexicon/api-usability.md)

Shape it refuses
[Ad-Hoc Endpoints](https://banes-lab.com/records/lexicon/ad-hoc-endpoints.md), [Chatty Interface](https://banes-lab.com/records/architecture/chatty-interface.md)

### Consumer-Driven Contracts

- Kind: [constraint](https://banes-lab.com/records/kind/constraint.md)
- Category: [Contracts / Interfaces / Compatibility](https://banes-lab.com/ontology/principles/architecture-category-contracts-interfaces-compatibility.md)
- Severity: [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- Scope: API, service, integration
- Layer: [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)

Details

Definition
A rule or precondition that a provider verifies each change against the expectations its consumers have recorded.

Requires
[Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md)

Reinforces
[Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md)

Enables
[Provider Change Safety](https://banes-lab.com/records/lexicon/provider-change-safety.md), [Consumer-Verified Compatibility](https://banes-lab.com/records/lexicon/consumer-verified-compatibility.md)

In tension with
[Provider Autonomy](https://banes-lab.com/records/lexicon/provider-autonomy.md)

Conflicts with
[Unversioned Breaking Change](https://banes-lab.com/records/architecture/unversioned-breaking-change.md)

Tensions
[Consumer-Driven Contracts / Provider Autonomy](https://banes-lab.com/records/tension/consumer-driven-contracts-provider-autonomy.md)

Violated by
providers changing responses with no consumer expectation check

Detected by
integration breaks discovered only in production

Measured by
consumer-break incident rate

Refactored by
Introduce Consumer-Driven Contract tests

Enforced by
contract test gate

Before

```typescript
fooProvider.deploy(newFooApi);
```

After

```typescript
const expectations = collectContractsFrom(["bar-service", "baz-service"]);
const result = verifyProvider(newFooApi, expectations);
if (!result.satisfied) throw new BrokenConsumerContractError(result.violations);
fooProvider.deploy(newFooApi);
```

How it is checked

Checked by
contract test gate

Population
Every public boundary: operations, endpoints, messages, schemas and protocol frames

Freshness
A verdict stands for one version of the contract and goes stale when the contract or its implementation changes

Refusal
The contract test, schema validation or API diff gate fails the change that breaks the contract

Observation
The contract or schema compared with the implementation and with each consumer's recorded expectation

Evidence
None, because the catalog states this check as a class, so a watched run belongs to each system that adopts it

Authoritative side
The contract, which the implementation and each consumer's recorded expectation are compared against

Depends on
[Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md), [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md), [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md), [Provider Change Safety](https://banes-lab.com/records/lexicon/provider-change-safety.md), [Consumer-Verified Compatibility](https://banes-lab.com/records/lexicon/consumer-verified-compatibility.md)

Shape it refuses
[Unversioned Breaking Change](https://banes-lab.com/records/architecture/unversioned-breaking-change.md)

## Links to

- [principle](https://banes-lab.com/records/kind/principle.md)
- [recommended](https://banes-lab.com/records/vocabulary/severity-recommended.md)
- [Contracts Core](https://banes-lab.com/records/layer/contracts-core.md)
- [Preconditions](https://banes-lab.com/records/architecture/preconditions.md)
- [Postconditions](https://banes-lab.com/records/architecture/postconditions.md)
- [Invariant](https://banes-lab.com/records/architecture/invariant.md)
- [Correctness](https://banes-lab.com/records/architecture/correctness.md)
- [Predictability](https://banes-lab.com/records/architecture/predictability.md)
- [Contract Testing](https://banes-lab.com/records/lexicon/contract-testing.md)
- [Liskov Substitution Principle](https://banes-lab.com/records/architecture/liskov-substitution.md)
- [Development Speed](https://banes-lab.com/records/lexicon/development-speed.md)
- [Implicit Behavior](https://banes-lab.com/records/lexicon/implicit-behavior.md)
- [Architectural Contract Algebra](https://banes-lab.com/records/algorithms/architectural-contract-algebra.md)
- [Contract-Based Verification Kernel](https://banes-lab.com/records/algorithms/contract-based-verification-kernel.md)
- [Design by Contract / Development Speed](https://banes-lab.com/records/tension/design-by-contract-development-speed.md)
- [Static Analysis](https://banes-lab.com/records/reasoning/technique-static-analysis.md)
- [mandatory](https://banes-lab.com/records/vocabulary/severity-mandatory.md)
- [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md)
- [Type Safety](https://banes-lab.com/records/architecture/type-safety.md)
- [Interoperability](https://banes-lab.com/records/architecture/interoperability.md)
- [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md)
- [Rapid Prototyping](https://banes-lab.com/records/lexicon/rapid-prototyping.md)
- [Implicit Contract](https://banes-lab.com/records/architecture/implicit-contract.md)
- [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md)
- [Autonomy](https://banes-lab.com/records/architecture/autonomy.md)
- [Contracts Core](https://banes-lab.com/records/algorithms/contracts-core.md)
- [PAG Authoring Kernel](https://banes-lab.com/records/algorithms/pag-authoring-kernel.md)
- [Explicit Contracts / Rapid Prototyping](https://banes-lab.com/records/tension/explicit-contracts-rapid-prototyping.md)
- [Determinism](https://banes-lab.com/records/architecture/determinism.md)
- [Independence](https://banes-lab.com/records/architecture/independence.md)
- [Schema Validation](https://banes-lab.com/records/architecture/schema-validation.md)
- [quality-attribute](https://banes-lab.com/records/kind/quality-attribute.md)
- [Versioning](https://banes-lab.com/records/architecture/versioning.md)
- [Backward Compatibility](https://banes-lab.com/records/architecture/backward-compatibility.md)
- [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md)
- [Replaceability](https://banes-lab.com/records/architecture/replaceability.md)
- [Independent Consumers](https://banes-lab.com/records/lexicon/independent-consumers.md)
- [Evolution Speed](https://banes-lab.com/records/lexicon/evolution-speed.md)
- [Breaking Changes](https://banes-lab.com/records/lexicon/breaking-changes.md)
- [Explicit Boundaries](https://banes-lab.com/records/architecture/explicit-boundaries.md)
- [Runtime Extensibility](https://banes-lab.com/records/architecture/runtime-extensibility.md)
- [Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md)
- [Interface-Based Design](https://banes-lab.com/records/architecture/interface-based-design.md)
- [API Contract](https://banes-lab.com/records/architecture/api-contract.md)
- [Encapsulation](https://banes-lab.com/records/architecture/encapsulation.md)
- [Composability](https://banes-lab.com/records/architecture/composability.md)
- [Dependency Inversion Principle](https://banes-lab.com/records/architecture/dependency-inversion.md)
- [Plugin Architecture](https://banes-lab.com/records/architecture/plugin-architecture.md)
- [Extension Points](https://banes-lab.com/records/architecture/extension-points.md)
- [Principle of Least Surprise](https://banes-lab.com/records/architecture/principle-of-least-surprise.md)
- [Stable Interfaces / Evolution Speed](https://banes-lab.com/records/tension/evolution-speed-stable-interfaces.md)
- [Schema Drift](https://banes-lab.com/records/architecture/schema-drift.md)
- [Abstraction](https://banes-lab.com/records/architecture/abstraction.md)
- [Testability](https://banes-lab.com/records/architecture/testability.md)
- [Dependency Injection](https://banes-lab.com/records/architecture/dependency-injection.md)
- [Adapter Pattern](https://banes-lab.com/records/architecture/adapter-pattern.md)
- [Interface Overuse](https://banes-lab.com/records/lexicon/interface-overuse.md)
- [Concrete Coupling](https://banes-lab.com/records/architecture/concrete-coupling.md)
- [Composition Over Inheritance](https://banes-lab.com/records/architecture/composition-over-inheritance.md)
- [Interface-Based Design / Interface Overuse](https://banes-lab.com/records/tension/interface-based-design-interface-overuse.md)
- [Schema Contract](https://banes-lab.com/records/architecture/schema-contract.md)
- [Consumer-Driven Development](https://banes-lab.com/records/lexicon/consumer-driven-development.md)
- [Iteration Speed](https://banes-lab.com/records/lexicon/iteration-speed.md)
- [Implementation-First Integration](https://banes-lab.com/records/lexicon/implementation-first-integration.md)
- [Contract-First Design / Iteration Speed](https://banes-lab.com/records/tension/contract-first-design-iteration-speed.md)
- [constraint](https://banes-lab.com/records/kind/constraint.md)
- [Schema](https://banes-lab.com/records/lexicon/schema.md)
- [Client Compatibility](https://banes-lab.com/records/lexicon/client-compatibility.md)
- [Evolution](https://banes-lab.com/records/lexicon/evolution.md)
- [Breaking API Change](https://banes-lab.com/records/lexicon/breaking-api-change.md)
- [Service Contract](https://banes-lab.com/records/architecture/service-contract.md)
- [Self-Describing API](https://banes-lab.com/records/architecture/self-describing-api.md)
- [API Contract / Evolution](https://banes-lab.com/records/tension/api-contract-evolution.md)
- [Semantic Contract](https://banes-lab.com/records/lexicon/semantic-contract.md)
- [Compatibility](https://banes-lab.com/records/lexicon/compatibility.md)
- [Independent Deployment](https://banes-lab.com/records/lexicon/independent-deployment.md)
- [Distributed Evolution](https://banes-lab.com/records/lexicon/distributed-evolution.md)
- [Hidden Service Coupling](https://banes-lab.com/records/lexicon/hidden-service-coupling.md)
- [Service-Oriented Architecture](https://banes-lab.com/records/architecture/service-oriented-architecture.md)
- [Service Contract / Distributed Evolution](https://banes-lab.com/records/tension/distributed-evolution-service-contract.md)
- [Semantic Consistency](https://banes-lab.com/records/architecture/semantic-consistency.md)
- [Data Quality](https://banes-lab.com/records/lexicon/data-quality.md)
- [Schema Evolution](https://banes-lab.com/records/lexicon/schema-evolution.md)
- [Flexible Ingestion](https://banes-lab.com/records/lexicon/flexible-ingestion.md)
- [Canonical Data Model](https://banes-lab.com/records/architecture/canonical-data-model.md)
- [Data Contract / Flexible Ingestion](https://banes-lab.com/records/tension/data-contract-flexible-ingestion.md)
- [Canonical Schema](https://banes-lab.com/records/architecture/canonical-schema.md)
- [Data Contract](https://banes-lab.com/records/architecture/data-contract.md)
- [Automated Validation](https://banes-lab.com/records/lexicon/automated-validation.md)
- [Schema Flexibility](https://banes-lab.com/records/lexicon/schema-flexibility.md)
- [Ad-Hoc Payloads](https://banes-lab.com/records/lexicon/ad-hoc-payloads.md)
- [Schema Contract / Schema Flexibility](https://banes-lab.com/records/tension/schema-contract-schema-flexibility.md)
- [Ubiquitous Language](https://banes-lab.com/records/architecture/ubiquitous-language.md)
- [Domain Model](https://banes-lab.com/records/architecture/domain-model.md)
- [Reliable Integration](https://banes-lab.com/records/lexicon/reliable-integration.md)
- [Cross-Domain Translation](https://banes-lab.com/records/lexicon/cross-domain-translation.md)
- [Ambiguous Naming](https://banes-lab.com/records/lexicon/ambiguous-naming.md)
- [Semantic Contracts / Cross-Domain Translation](https://banes-lab.com/records/tension/cross-domain-translation-semantic-contracts.md)
- [Input Validation](https://banes-lab.com/records/architecture/input-validation.md)
- [Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md)
- [Fail Fast](https://banes-lab.com/records/architecture/fail-fast.md)
- [Permissive APIs](https://banes-lab.com/records/lexicon/permissive-apis.md)
- [Implicit Assumptions](https://banes-lab.com/records/lexicon/implicit-assumptions.md)
- [Preconditions / Permissive APIs](https://banes-lab.com/records/tension/permissive-apis-preconditions.md)
- [Validation Rules](https://banes-lab.com/records/lexicon/validation-rules.md)
- [Result Validation](https://banes-lab.com/records/lexicon/result-validation.md)
- [Runtime Cost](https://banes-lab.com/records/lexicon/runtime-cost.md)
- [Undefined Results](https://banes-lab.com/records/lexicon/undefined-results.md)
- [Postconditions / Runtime Cost](https://banes-lab.com/records/tension/postconditions-runtime-cost.md)
- [Validation](https://banes-lab.com/records/architecture/validation.md)
- [Consistency](https://banes-lab.com/records/architecture/consistency.md)
- [Safe Refactoring](https://banes-lab.com/records/lexicon/safe-refactoring.md)
- [Flexibility](https://banes-lab.com/records/lexicon/flexibility.md)
- [External State Mutation](https://banes-lab.com/records/lexicon/external-state-mutation.md)
- [Aggregate](https://banes-lab.com/records/architecture/aggregate.md)
- [Invariant / Flexibility](https://banes-lab.com/records/tension/flexibility-invariant.md)
- [Consumer Safety](https://banes-lab.com/records/lexicon/consumer-safety.md)
- [Incremental Deployment](https://banes-lab.com/records/lexicon/incremental-deployment.md)
- [Cleanup / Simplification](https://banes-lab.com/records/lexicon/cleanup-simplification.md)
- [Breaking Change](https://banes-lab.com/records/lexicon/breaking-change.md)
- [Declared Jurisdiction](https://banes-lab.com/records/architecture/declared-jurisdiction.md)
- [Backward Compatibility / Cleanup / Simplification](https://banes-lab.com/records/tension/backward-compatibility-cleanup-simplification.md)
- [Extensible Schema](https://banes-lab.com/records/lexicon/extensible-schema.md)
- [Evolutionary Architecture](https://banes-lab.com/records/architecture/evolutionary-architecture.md)
- [Rolling Upgrades](https://banes-lab.com/records/lexicon/rolling-upgrades.md)
- [Strong Validation](https://banes-lab.com/records/lexicon/strong-validation.md)
- [Strict Fragile Parsers](https://banes-lab.com/records/lexicon/strict-fragile-parsers.md)
- [Forward Compatibility / Strong Validation](https://banes-lab.com/records/tension/forward-compatibility-strong-validation.md)
- [mechanism](https://banes-lab.com/records/kind/mechanism.md)
- [Compatibility Policy](https://banes-lab.com/records/lexicon/compatibility-policy.md)
- [Governance](https://banes-lab.com/records/architecture/governance.md)
- [Controlled Evolution](https://banes-lab.com/records/lexicon/controlled-evolution.md)
- [Version Sprawl](https://banes-lab.com/records/lexicon/version-sprawl.md)
- [Silent Breaking Changes](https://banes-lab.com/records/lexicon/silent-breaking-changes.md)
- [Protocol Compatibility](https://banes-lab.com/records/architecture/protocol-compatibility.md)
- [Integration Events](https://banes-lab.com/records/architecture/integration-events.md)
- [Versioned Evolution Over Breaking Change](https://banes-lab.com/records/algorithms/no-breaking-change.md)
- [Living Profile Kernel](https://banes-lab.com/records/algorithms/living-profile-kernel.md)
- [Versioning / Version Sprawl](https://banes-lab.com/records/tension/version-sprawl-versioning.md)
- [Protocol Contract](https://banes-lab.com/records/lexicon/protocol-contract.md)
- [Multi-Client Integration](https://banes-lab.com/records/lexicon/multi-client-integration.md)
- [Protocol Optimization](https://banes-lab.com/records/lexicon/protocol-optimization.md)
- [Proprietary Drift](https://banes-lab.com/records/lexicon/proprietary-drift.md)
- [Protocol Compatibility / Protocol Optimization](https://banes-lab.com/records/tension/protocol-compatibility-protocol-optimization.md)
- [Contracts](https://banes-lab.com/records/lexicon/contracts.md)
- [Standards](https://banes-lab.com/records/lexicon/standards.md)
- [Portability](https://banes-lab.com/records/architecture/portability.md)
- [Integration](https://banes-lab.com/records/lexicon/integration.md)
- [Cross-System Communication](https://banes-lab.com/records/lexicon/cross-system-communication.md)
- [Domain-Specific Optimization](https://banes-lab.com/records/lexicon/domain-specific-optimization.md)
- [Proprietary Coupling](https://banes-lab.com/records/lexicon/proprietary-coupling.md)
- [Standards Compliance](https://banes-lab.com/records/architecture/standards-compliance.md)
- [Robustness Principle](https://banes-lab.com/records/architecture/robustness-principle.md)
- [Standardization](https://banes-lab.com/records/architecture/standardization.md)
- [Interoperability / Domain-Specific Optimization](https://banes-lab.com/records/tension/domain-specific-optimization-interoperability.md)
- [Discoverability](https://banes-lab.com/records/lexicon/discoverability.md)
- [Consistent Semantics](https://banes-lab.com/records/lexicon/consistent-semantics.md)
- [Stable Contracts](https://banes-lab.com/records/lexicon/stable-contracts.md)
- [API Usability](https://banes-lab.com/records/lexicon/api-usability.md)
- [Specialized Endpoints](https://banes-lab.com/records/lexicon/specialized-endpoints.md)
- [Ad-Hoc Endpoints](https://banes-lab.com/records/lexicon/ad-hoc-endpoints.md)
- [Chatty Interface](https://banes-lab.com/records/architecture/chatty-interface.md)
- [Composite Pattern](https://banes-lab.com/records/architecture/composite-pattern.md)
- [Uniform Interface / Specialized Endpoints](https://banes-lab.com/records/tension/specialized-endpoints-uniform-interface.md)
- [Provider Change Safety](https://banes-lab.com/records/lexicon/provider-change-safety.md)
- [Consumer-Verified Compatibility](https://banes-lab.com/records/lexicon/consumer-verified-compatibility.md)
- [Provider Autonomy](https://banes-lab.com/records/lexicon/provider-autonomy.md)
- [Unversioned Breaking Change](https://banes-lab.com/records/architecture/unversioned-breaking-change.md)
- [Consumer-Driven Contracts / Provider Autonomy](https://banes-lab.com/records/tension/consumer-driven-contracts-provider-autonomy.md)

## Linked from

- [The layer topology](https://banes-lab.com/ontology/schema/the-layer-topology.md)
- [The membership](https://banes-lab.com/ontology/schema/the-membership.md)