Edition 0.3.0 · Doctrine for Rust engineering · Search alias: USaT
Purpose
Software must carry an organization's commitments without quietly taking over the authority to change them. A commitment is something the product owes: work it permits, conditions it must respect, an outcome, or a follow-up it must own.
The doctrine puts deliberate resistance around changing those commitments. Implementation underneath them should remain replaceable. An engineer should be able to improve storage, replace an adapter or simplify a helper without reconstructing every business decision from scattered checks.
This matters because producing more code is not the same as preserving meaning. A new contributor or agent can make a local change that compiles while widening who may act, losing the version that was approved, or abandoning unfinished work. Readable contracts, consequential type relationships and current-fact checks reduce that dependence on memory and repeated manual policing.
The compiler enforces relationships that have been encoded. It cannot establish whether a policy is wise, a person currently has authority, a database row has changed, or an external effect happened. Responsibility for those facts remains with their owners.
Doctrine, Patterns and Teaching
| Form | What it supplies | What it cannot supply |
|---|---|---|
| Doctrine | Governing commitments, reasons, authority boundaries and judgment about change | An organization's business mandate |
| Design pattern | A reusable arrangement for a particular design problem | Permission to change the product's promise |
| Architecture classification | Questions and representations needed to describe a system | A development or release sequence |
| Thinking tool | A way to investigate a question or compare consequences | Evidence that an assumption is true |
| Human course | Worked examples, explanations, comparisons and practice | Additional rules merely because an example uses them |
| Agent guide | Compact application and retrieval guidance | A second independently editable doctrine |
Typestate, private fields, associated types and transaction capabilities are possible mechanisms. A collection of those mechanisms is not, by itself, this doctrine. Compliance concerns the commitment they express and enforce.
Projects own their business policy, workflow, configurations and release cadence. This document does not prescribe a universal first command, test suite, approval ceremony, framework, or number of traits. Its implementation scope is Rust; it does not authorize rewriting another language or product.
Vocabulary
| Term | Meaning |
|---|---|
| Story | The compile-time abstraction expressing a selected commitment and its relationships |
| Realization | The code and collaborators that implement that story |
| Occurrence | Actual work bound to particular actors, input, versions and resources |
| Composition | Independently owned commitments joined through admissible relationships |
| Chain | What established work allows a legitimate successor to consume or do |
| Telescoping | Following the same commitment from its readable entrance into the relevant detail |
| Authority | A mandate to decide or act, within its scope and current conditions |
| Invariant | A condition that must remain true within its stated boundary |
| Capability | A value or contract that permits a particular operation under its guarantees |
| Obligation | Work that remains owed, including after its initiating request ends |
A story can select Google identity, no password collected during registration, an entry policy and independent confirmation work. Ari registering now is an occurrence. The provider and store used for Ari's registration are actual resources, not merely generic type names.