Zachman helps classify the descriptions needed to understand, build and change a system. Its six questions are crossed with six transformations from an idea to an operating instance. It does not prescribe a delivery process.
This is an original worked application of that classification to the workshop reference. It is not a reproduction of the official framework graphic or a claim that one example describes a whole enterprise. Sources: framework definition and Zachman on reification.
Six Questions
| Question | Kind of description | Workshop question |
|---|---|---|
| What | Things and their relationships | What are registration, account, session and confirmation work? |
| How | Transformations and their inputs/outputs | How does an assertion lead to a recorded registration? |
| Where | Distribution and connections | Where are identity checked, records held and messages delivered? |
| Who | Responsibility and assignment | Who decides entry policy, acts, benefits and owns follow-up? |
| When | Events, order and timing | When may someone enter, when does the session expire, and when is work still owed? |
| Why | Ends, means and governing reasons | Why is entry allowed before confirmation, and what must that choice preserve? |
The questions are different. A method called approve() describes an operation;
it does not identify who may approve. A module named identity is a source-code
location; it does not tell us where the real identity service runs. A timeout is
an event; it does not explain why an effect is unknown or authorize a retry.
Six Transformations
| Transformation | What changes in the description | A question it can answer |
|---|---|---|
| Identification | Name the relevant things, work and boundaries | What belongs in this story's scope? |
| Definition | Establish their business meaning and relationships | What does “may enter” mean? |
| Representation | Model that meaning without committing to a specific technology | What facts and relationships must any realization preserve? |
| Specification | Choose a technical realization | How will Rust and storage enforce the relationships? |
| Configuration | Produce the particular configured components | Which implementation, configuration and artifacts will run? |
| Instantiation | Operate a particular instance | What actually happened to this registration? |
These are not six amounts of detail, six Rust stages, six departments, or a waterfall schedule. Each representation can be coarse or detailed. Telescoping lets a reader reach relevant detail; a Zachman transformation changes the kind of representation being described.
For example, the sentence “valid sessions may enter before confirmation” and the
Rust selection CookieValid belong to related but different representations.
Neither the words nor the type proves that a particular session is valid now.
The Bounded Example
The workshop selects Google identity, no password collected at registration, an
entry rule, and independent confirmation work. The reference implements two
entry choices: CookieValid and ConfirmedOnly.
The reference is deliberately in-memory. Its demonstration verifier compares strings; its delivery changes a local record. The following map separates those fixtures from the external services a deployed authentication product would need.
Identification
| Question | Description at This Transformation |
|---|---|
| What | Participant, submitted identity assertion, registration, account, session and confirmation work are in scope. |
| How | Verify identity, admit registration, record it, enter, deliver and confirm are the relevant work areas. |
| Where | The boundary includes the participant, the workshop service, an identity provider and a delivery destination; their physical deployment is not chosen here. |
| Who | The participant initiates registration; the workshop owner sets its policy; the service and delivery owner carry the work. |
| When | Registration, initial entry, later visits, session expiry and unfinished confirmation are relevant events. |
| Why | Let an eligible participant use the workshop under a chosen entry policy while retaining the owed confirmation. |
Definition
| Question | Description at This Transformation |
|---|---|
| What | Registration establishes one account for a verified subject. A session permits later admission checks; a confirmation ticket denotes owed work. |
| How | Identity verification precedes registration admission. Recording creates session facts and an independent confirmation obligation. Sending and confirming are different acts. |
| Where | Identity observations cross into the workshop's decision boundary. Account/session/owed-work facts belong to the workshop; a genuine delivered message would be an external effect. |
| Who | The product owner chooses pre-confirmation entry policy. The participant benefits from entry. The service must not make delivery the participant's responsibility merely because their browser closed. |
| When | Entry requires a current, active, unexpired session. The selected confirmation condition applies to both initial and later entry. Revocation is not undone by confirmation. |
| Why | Separate entry from confirmation so the selected product policy, rather than an incidental call order, decides whether one waits for the other. |
Representation
| Question | Description at This Transformation |
|---|---|
| What | Model subject identity, account/session facts, confirmation status, operation ownership and the association between a handle and its workshop. |
| How | Model a verification result that enables admission, an admitted registration that can be recorded, and independent entry/delivery continuations. |
| Where | Distinguish a verifier interface, an owning account store and a delivery interface. A handle must retain the identity of its owning store/instance. |
| Who | Distinguish the authority that chooses a policy from the caller using it and the trusted adapter reporting identity facts. Arbitrary callers cannot manufacture protected progression. |
| When | Model current-time admission, refusal on expiry/revocation, pending delivery after a dropped handle, and harmless repeated observations. |
| Why | Make the permitted choices and their consequences inspectable before choosing a storage engine, network library or source layout. |
Specification
| Question | Description at This Transformation |
|---|---|
| What | Rust private carriers retain the subject and workshop borrow. Session and confirmation handles retain an Arc identity and private account slot. |
| How | VerifyIdentity, AdmitRegistration, RecordRegistration and their associated successors constrain the chain. Entry and follow-up contracts remain reachable from WorkshopStories. |
| Where | The reference uses one process and an in-memory vector. A borrowed workshop excludes interleaving mutation during registration. This is not a distributed store design. |
| Who | Closed policy implementations select supported entry authority. GoogleIdentity is an open trusted adapter contract. Model-control methods are trusted test controls, not authorized end-user endpoints. |
| When | A monotonic model clock defines a ten-tick session. Each visit checks current facts. Owed work remains in the workshop aggregate while that aggregate lives. |
| Why | Use Rust ownership, private construction and associated relationships to preserve this model's promise without claiming network authentication or crash durability. |
Configuration
| Question | Description at This Transformation |
|---|---|
| What | OpenWorkshop<P> selects Google<P>, WithoutPassword and CookieValid; ConfirmedWorkshop<P> selects ConfirmedOnly. The fixture supplies an assertion and subject. |
| How | The generic consumer in tests/flows.rs follows the root contract through verification, admission, recording and follow-up extraction. |
| Where | DemonstrationGoogle and the workshop store are configured in the local test process. No provider endpoint, database connection or mail service is configured. |
| Who | Trusted test setup chooses the fixture and policy. That setup has not supplied a real organization's membership, delegation or deployment authority. |
| When | Tests explicitly choose model ticks, interruptions and later visits. A configured expiration rule is distinguishable from a current clock observation. |
| Why | Two configured policy selections let readers compare consequences while the identity, recording and follow-up requirements remain the same. |
Instantiation
| Question | Description at This Transformation |
|---|---|
| What | In the positive reference case, subject-a has one recorded account, a session and one owed confirmation. These are particular fixture values. |
| How | The executed consumer verifies, admits and records; entry succeeds under the open policy. Dropped delivery handles leave work discoverable for later completion. |
| Where | The facts exist in that actual workshop object in the running test process. A matching slot in another object is rejected as foreign work. |
| Who | The configured demonstration verifier supplied the subject observation; the workshop applied its selected rule. This does not identify or authorize a real person. |
| When | Entry, expiry, revocation and confirmation assertions observe the model at particular ticks. Destroying the process loses its in-memory obligations. |
| Why | Observed outcomes show whether this bounded realization follows its selected promise. They do not establish that the policy is suitable for a production service. |
Reading a Change Across the Map
Change the business decision from pre-confirmation entry allowed to confirmation
required. The Why and How/When definitions must now agree with that choice.
The representation needs an entry condition that reaches every relevant visit.
The technical selection changes from CookieValid to ConfirmedOnly. Runtime
observations must show refusal before confirmation and allowance afterward, while
still refusing expired or revoked sessions.
Changing only an enum label in a diagram would not complete those transformations. Changing only initial entry while leaving later visits open would not preserve the newly selected meaning. Conversely, this decision does not require changing the identity provider or making confirmation delivery depend on entry.
Use the Map Without Creating Ceremony
For a real change, identify the affected questions and representations. Follow their relationships far enough to find the consequence. Mark unavailable facts as unknown and out-of-scope work as an explicit boundary.
A filled cell is not proof of correctness. The map can be supported by code, schemas, decisions, configuration or observations already owned by the project. It does not require a new document for each cell or override the project's release workflow.