# Chainable + Composable Traits as Stories with Telescopic Organization 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. ## D1 · The Story Owns the Commitment Start with what the product owes and who owns that decision. Expose the meaningful choices, prerequisites, results and continuations at the story's governing surface. Where Rust can make a relationship a condition of construction or use, encode it there. **Why:** a requirement enforced only by repeated caller discipline is easy to forget. A named trait with no consequential relationship is equally easy to bypass. Neither makes the product's promise reliably visible. **Consequence:** changing a bound, constructor or implementation so that more behavior becomes possible is a design decision. Determine whether the current task authorizes that changed promise. A green build supplies no mandate. An ordinary function can serve a leaf or a trivial operation. A pattern or framework must not force the product to acquire stages or alternatives it never owed. ## D2 · Completeness Has a Jurisdiction Name what the story owns and what belongs to another owner. Account for the relevant actor, beneficiary, mandate, exact work, outcomes and continuations inside that scope. Reuse another owner's exposed contract when needed. **Why:** omissions lose obligations, while invented responsibility creates authority the story never had. Completeness is meaningful only against a named boundary. **Consequence:** removing password collection from registration does not decide all later login policy. An entry story can depend on session facts without owning the whole account lifecycle. An automated counterpart does not become the initiating person's contribution, and two department contexts do not create two independent people. MECE means mutually exclusive, collectively exhaustive: branches do not overlap and together cover the chosen question. It is useful for a bounded analysis, not a claim that one model exhausts the enterprise. ## D3 · Share Deliberately; Preserve Independent Evolution Share common policy or capability when its consumers are meant to change together. Similar code alone does not establish shared authority or a shared reason to change. Keep independent commitments free to evolve independently. **Why:** a helper can acquire accidental authority when unrelated features must negotiate with it merely to preserve reuse. Conversely, duplicating one official policy lets its intended consumers disagree. **Consequence:** preview wording and archival wording may need separate leaves; badge and manifest identifiers may need one shared policy. Sharing vocabulary, code, policy, state and deployment are separate decisions. A current semantic boundary or substitution requirement can justify one implementation behind a contract. Hypothetical future flexibility cannot. DRY (Don't Repeat Yourself), KISS (Keep It Simple) and YAGNI (You Aren't Gonna Need It) are aids to judgment, not higher authorities than the promised behavior. ## D4 · Continuity Carries Actual Work Bind and retain the actor, subject, scope, version, operation, evidence and actual resources on which a continuation relies. Compatible Rust types do not prove that two values identify the same occurrence. Compare runtime identities where required, or retain the resource itself behind an appropriate ownership or borrowing boundary. **Why:** approving version 7 and later executing version 8 is not continuity. Nor is sending store A's record 7 to store B because their identifier types match. **Consequence:** a successor must not silently substitute work. New evidence can be legitimate later input when it refers to the original operation. Recovery preserves that operation and what is known about it. A later visit is admitted again against current facts. State carriers may own data. Zero-sized markers are optional and appropriate only for distinctions that need no carried data. Construction, mutation, deserialization and cloning must not forge protected progression. Consume a value where local reuse is invalid; seal a surface where arbitrary implementations would forge authority. Keep intended trusted adapter ports open. Mutable authority, expiry, revocation and stored versions need current checks at the owning boundary. Do not keep a database transaction open across human delay just to retain a Rust type. Persist the right facts and re-establish admission when work resumes. ## D5 · Bound the Consumer's Expectations Expose the alternatives and obligations that the selected commitment really has. An established prerequisite should not become an avoidable flag or optional value that every leaf must rediscover. Genuine runtime alternatives remain explicit and can lead to protected continuations. **Why:** a simple-looking interface can conceal uncertainty and encourage unsafe retries. An excessively general interface can burden every consumer with outcomes that its operation cannot have. **Consequence:** a known pending operation, an unknown result, an applied effect and a failed view refresh are different facts. Recording a rejection can be a successful review; refusing an unauthorized review is another outcome. A pure label formatter may remain total. There is no universal outcome enum. Moves restrict local reuse. They do not establish completion, crash durability, external truth or distributed exactly-once effects. Outstanding work needs an owner and a survival mechanism for the boundary promised. A browser presents server-owned outcomes; a cached action or serialized receipt is not current server authority. ## D6 · Make the Governing Surface Readable and Consequential Let a domain owner review the selected promise without auditing the machinery. Let engineers follow the same names into compatible constituents, successors, actual bindings and effects. Each step inward must answer a relevant question while preserving the meaning of the wider view. **Why:** a contract that only its author can reconstruct makes that author a permanent part of the system. Comments and diagrams cannot rescue executable relationships that contradict their readable promise. **Consequence:** roots and composition points select realizations and bind work; they should not become global service locators. Source layout helps navigation but is not the whole story. A large implementation diagram does not become a business contract by being placed at the root. Parameterization should express meaningful choices and admissible combinations. Associated types, data-bearing collaborators, concrete carriers and ordinary values have different jobs. Consumers should not have to restate hidden concrete types to follow a declared successor relationship. ## D7 · Evidence Protects the Commitment Use compiler feedback for encoded relationships and appropriate observations for behavior the compiler cannot know. Ask which requirement gives an assertion its authority. Preserve legitimate behavior and compatibility; retire checks that only preserve a discarded private arrangement. **Why:** implementation and test can repeat the same mistake. Counting tests, traits or passing checks does not establish the intended promise. **Consequence:** use independent expectations where that risk matters, and report unexecuted checks honestly. An adapter invocation does not prove a real effect. If a project maintains negative compiler examples, they must fail at their claimed boundary with a working valid use in the same environment. Projects decide whether and how to maintain such examples, and choose their own development and release sequence. This doctrine neither requires nor bans `tests/ui`, `trybuild` or another project-specific check. Human learning exercises are judged by their designated human reviewer. ## D8 · Govern Change, Not Repetitive Human Vigilance Distinguish implementation replacement, representation change, altered promises, authority expansion, consumer compatibility and migration of outstanding work. Use the accountable owner's mandate and the project's actual workflow. **Why:** one changed line can widen authority; hundreds of changed lines can preserve it. Mechanical enforcement should carry established decisions so that review can focus on their meaningful changes and remaining runtime risks. **Consequence:** protect the governing boundary and its enforcement with appropriate repository controls. Rust privacy does not stop an authorized editor from changing the protected source. An instruction file points to authority; it does not replace it. Already authorized implementation does not acquire a new approval ceremony merely because this doctrine exists. Retirement needs a disposition for consumers, history and unfinished obligations. Removing an entrance for new work does not complete old work. Preserve neither a bad abstraction nor redundant documentation solely because it has accumulated. ## Architecture Questions: Using Zachman Zachman classifies architectural descriptions using six questions and six transformations from an idea to its operating instance. It is not a development process. Its rows are transformations of representation, not levels of detail or steps in a runtime story. [Framework definition](https://zachman-feac.com/zachman/about-the-zachman-framework), [Zachman on the rows](https://zachman-feac.com/resources/blog/zachman-framework-rows-what-are-they-1?format=amp). | Question | What this doctrine requires us to keep intelligible | |---|---| | What | Commitments, selected choices, records, evidence and actual work | | How | Permitted operations and the relationships between constituents and successors | | Where | Ownership, resource custody and execution/distribution boundaries; source modules alone are insufficient | | Who | Decision owner, actor, beneficiary and responsibility for follow-up | | When | Trigger, order, validity window, interruption and survival of owed work | | Why | Product purpose, policy rationale, constraints and the reason for a change | Different representations answer these questions differently. A business owner defines what entry means and why it is allowed. An engineer models its relationships. A builder chooses Rust/storage mechanisms. An operating instance supplies actual events and evidence. None may silently invent the meaning owned by another representation. The [worked Zachman map](zachman.md) follows one workshop through all 36 intersections. It exposes the demonstration model's omissions as omissions: its fixture identity is not Google authentication, and its memory is not durable storage. It does not pretend to model the entire enterprise. Use the classification to discover a missing question, mismatched representation or unsupported claim. Do not require 36 new documents for every edit, reinterpret telescoping as Zachman's rows, or use the matrix as an automated conformance score. ## Reasoning Tools and Their Limits The [thinking-tools guide](thinking-tools.md) selects six tools from Untools for concrete questions: abstraction laddering, concept mapping, issue trees, the ladder of inference, second-order thinking and inversion. They support framing, explanation, investigation and comparison. They are not extra authority and are not compulsory steps for every task. For example, inversion can expose a public constructor that would allow a caller to forge approval. It does not decide who should approve. A consequence map can reveal which consumers change together; it does not decide their owners' policy. ## Interpretation and Change Use the smallest truthful arrangement that preserves the commitment, its current facts and understandable evolution. An alternative implementation can satisfy the doctrine; a visual copy of a reference can violate it. The human course develops judgment through examples. The agent guide applies these commitments compactly. Their examples, tools and incidental implementation choices do not amend this document by repetition. Changes to the doctrine should state the changed commitment, reason and consequences and preserve source lineage. The owner's wider term **derivability** is not reduced here to a derive macro, inheritance or an associated-type trick. The materials demonstrate consequence tracing: predict what a changed selection permits, then follow its realization. No additional formal claim is silently attached to that term.