Objects, Morphisms, and Composition

Once a workflow has explicit responsibility boundaries, the next question is which parts of that workflow are stable enough to deserve names and laws. The core compositional vocabulary of objects, morphisms, and composition answers that question for systems, interfaces, and transformations. The chapter keeps the minimal example and the common running example nearby so the formal language stays tied to reviewable artifacts. Use Appendix A for notation and Appendix B for canonical definitions.

Learning goals

• Choose stable software artifacts and states that are worth modeling as objects.
• Distinguish meaningful morphisms from incidental implementation detail.
• Use composition, identity, and contract boundaries to reason about longer workflow claims.

Prerequisites

• The responsibility-boundary framing from Chapter 01.
• Basic comfort reading repository artifacts and workflow diagrams.

Key concepts

• object
• morphism
• composition
• identity morphism

Running example linkage

• The minimal diagram and the artifact map are the canonical sources behind Figure 2.1 and Table 2.1.
• For a first reading, the local figure and table carry the model-selection argument, while the linked artifacts remain the repository detail for later inspection.
• A smaller deployment-approval cue will recur when the same object-and-morphism choices apply to Deployment Request, Release Plan, and Approved Release without replacing the canonical repository example.

Modeling systems as objects

The argument does not begin by treating every file, function, or event as an object. It begins by asking which units stay stable enough to support review, reuse, and traceable change.

Choosing the right units of design

An object in this book is a stable unit of design, not simply anything that exists in the system. The unit is worth modeling as an object when it has a recognizable boundary, a durable role, and a review consequence if it changes incorrectly.

In the running example, Change Request, Review Plan, and Approved Change satisfy those conditions. Each one is a durable artifact class with a specific role in the workflow. Each one can be inspected independently. Each one can also fail in a different way.

For the same reason, the model does not start with prompts, model weights, or individual shell commands. Those details may matter later, especially when effect boundaries become explicit. At this stage, they are usually implementation detail rather than the stable unit the reviewer needs.

The right object choice is therefore driven by boundaries and invariants. If a unit carries a distinct contract, can survive a handoff, and supports a separate review question, it is a strong candidate for object status. If it exists only as a transient implementation convenience, it usually should not anchor the model.

Figure 2.1 shows the smallest object-and-morphism chain that the rest of the book reuses.

Figure 2.1. The running example becomes a model only when stable artifacts and named transformations are explicit.

Reader takeaway. Objects give the approval path durable boundaries, and morphisms state what each step must preserve across those boundaries.

Table 2.1. Minimal modeling map for the running example.

Objects as stable interfaces and states

Software objects in a compositional model can represent either stable interfaces or stable states. The difference matters less than the fact that the unit remains identifiable across transformations. The Change Request is a stateful artifact that captures intent, scope, and constraints. The Review Plan is a reviewable interface between request interpretation and approval. The Approved Change is the state reached after the required gate conditions hold.

This view prevents a common modeling error. Teams often talk about “the workflow” as if it were one object. That collapse hides the fact that the workflow crosses multiple boundaries with different obligations. A single blob cannot explain where a request becomes reviewable, where policy is checked, or where human judgment enters.

Object choice therefore stabilizes the later argument. If the reader cannot tell what counts as the same object before and after a step, it becomes impossible to state whether a transformation preserved meaning. Object selection is therefore the first modeling decision, not an afterthought.

Morphisms as interfaces and transformations

Once the objects are chosen, the next question is how one valid state or artifact becomes another. The answer is not every implementation step. It is the transformation that preserves the structure the model cares about.

Behavior-preserving change

A morphism is a named transformation between objects. In software design, that name should capture the meaningful change rather than the incidental mechanism. draft-review-plan is a better morphism name than “run model with prompt template 7” because the former states the transformation the reviewer actually cares about.

The morphism claim becomes stronger when the preserved behavior is explicit. In the running example, draft-review-plan should preserve the relevant scope and constraints of the Change Request. human-approval should preserve the judgment that the plan is acceptable under the stated policy and acceptance criteria.

Morphisms are design claims before they are implementation claims. A script, API call, or agent interaction may realize the morphism, but it is not identical to the morphism. If the implementation changes while the preserved artifact relationship stays the same, the morphism is stable. If the implementation silently drops a constraint, the morphism claim has failed even if the code still runs.

The minimal diagram makes this concrete. It names both the stepwise path and the direct path. The direct edge policy-gated-approval only makes sense if the composed steps preserve the same meaning as the shorter claim.

Partial functions, total functions, and contracts

Many software transformations are not defined for every conceivable input. That does not make them useless. It means the team must be honest about the domain on which the transformation is intended to work.

A total function is defined for every input in its stated domain. A partial function is defined only when additional preconditions hold. In practice, many workflow steps that teams informally describe as universal are partial once their real constraints are stated.

draft-review-plan may be total over well-formed Change Request artifacts that include scope, constraints, and acceptance criteria. It is not total over arbitrary text pasted into an issue tracker. human-approval is also partial if the plan may be rejected, escalated, or returned for revision rather than approved directly.

Interface contracts make this manageable. They state what a valid source object must contain and what a successful target object must guarantee. When the contract is missing, a workflow appears smoother than it really is. When the contract is explicit, the team can decide whether to narrow the domain, add a pre-validation step, or model alternative outcomes more explicitly in later chapters.

Composition as the core design move

The real power of the vocabulary appears when the team composes several trustworthy steps into one larger claim. Composition is the move that lets a local artifact transformation become a system-level argument.

Associativity and modular reasoning

If one morphism takes Change Request to Review Plan, and another takes Review Plan to Approved Change, then the two can compose into a path from request to approved change. In notation, human-approval ◦ draft-review-plan states that the second step is applied after the first. The notation matters here because order is part of the design claim.

The running example uses a direct edge called policy-gated-approval. That edge is not a shortcut for convenience only. It is a claim that the composed path preserves the same meaning the workflow wants the direct path to denote.

Associativity makes this useful in larger systems. If the workflow later inserts request normalization or policy evidence generation before approval, the team can regroup the composed path without changing its meaning as long as the interfaces still align. That is what allows modular reasoning. Different engineers can review adjacent parts of the path without losing the whole-system claim.

None of this is abstract bookkeeping. It affects how repositories are reviewed. A team can validate one morphism against one contract, then compose the approved steps into a larger workflow argument. Without associativity, every longer path would have to be re-argued from scratch.

Identity morphisms and boundary stability

An identity morphism leaves an object unchanged under composition. In software terms, it represents a step that preserves the object’s modeled meaning exactly. This matters because workflows often contain pass-through steps that should not alter the artifact they carry.

For example, a repository service may reformat metadata, reindex a request, or move an artifact between storage locations. If those steps preserve the modeled Change Request exactly, they behave like identity morphisms with respect to this chapter’s design model. If they alter scope, constraints, or reviewer obligations, they are not identities and should not be treated as harmless plumbing.

Identity morphisms therefore test boundary stability. A stable boundary allows a no-op pass-through without changing the artifact’s design meaning. An unstable boundary forces every transport or serialization step to become a semantic risk. That instability is expensive because it expands the number of places where the team must re-check invariants.

Translating the vocabulary into engineering practice

The formal vocabulary earns its place only when it improves design and review decisions. This section translates objects, morphisms, and composition into the day-to-day work of services, repositories, and review checkpoints.

Service interactions and data transformations

The same object and morphism language works outside the running example because most software systems already rely on stable boundaries. An API request can be modeled as an object when its schema and guarantees matter. A schema translation can be modeled as a morphism when the preserved fields and constraints are explicit. A deployment manifest can be an object when later steps depend on its contract rather than on one tool’s internal representation.

The canonical example keeps the discussion grounded. The problem statement provides the source boundary. The artifact map shows the durable units that matter across phases. The design diagram then states the composition claim that later chapters will test more rigorously.

Transfer cue: deployment approval pipeline. The same modeling choice appears when a Deployment Request becomes a Release Plan and then an Approved Release. The repository example remains canonical, but a release workflow still needs one stable request, one bounded plan, one approved outcome, and one execution boundary before a reviewer can trust the longer path.

The vocabulary helps teams separate model from mechanism. An AI agent, a service call, and a script may all realize the same morphism if they preserve the same contract. The tool choice still matters operationally, but it should not be confused with the design relation being claimed.

Composition in review checklists

Compositional reasoning can be turned into a practical review checklist. Before trusting a workflow path, ask the following questions.

• What is the source object, and what is the target object?
• Which invariant or contract must the morphism preserve?
• Is the transformation total on its stated domain, or does it depend on hidden preconditions?
• What evidence artifact shows that the transformation actually preserved the claimed structure?
• If multiple steps are composed, who owns the approval for the composed path as a whole?

These questions are useful in pull requests, design reviews, and workflow approvals because they expose hidden assumptions early. They also prepare the reader for Chapter 03, where diagrams make these path claims easier to inspect.

Common modeling mistakes

Most failed models are not wrong because the team lacks formal vocabulary. They fail because the model hides boundaries, smuggles in implementation detail, or assigns too much meaning to one overloaded node.

Overloading one object with multiple concerns

One common mistake is to treat one object as if it carried several unrelated responsibilities. In the running example, calling the whole approval workflow one object would erase the difference between request intent, reviewable plan, and approved outcome. It would also hide where distinct actors gain or lose authority.

A similar problem appears when the Review Plan is treated as both the proposal artifact and the complete record of approval. Those roles may overlap in a small example, but they are not conceptually identical. When one object carries too many concerns, later chapters cannot state clean morphisms or clean commutative claims.

The corrective move is simple. Split the model where the review question changes. If a reviewer would ask a different question about one part of the state than another, the model probably needs separate objects.

Mistaking implementation detail for structure

The opposite mistake is to model transient implementation choices as if they were the stable structure. Prompt phrasing, one temporary file path, or one internal API name may matter operationally, but they are often not the object or morphism the design argument depends on.

This matters especially in AI-assisted systems because implementations change quickly. If the model is built from volatile detail, every prompt revision appears to invalidate the entire design. If the model is built from stable contracts and preserved transformations, the team can change tools without rewriting the conceptual map.

The test is whether the design claim survives a tool substitution. If one agent platform is replaced with another and the preserved artifact path remains the same, the object and morphism model was probably well chosen. If the model collapses immediately, it was describing mechanism rather than structure. With those object and morphism choices in place, Chapter 03 can ask the next harder question of whether multiple paths through the model still preserve one coherent meaning.

Summary

• Objects should name stable artifacts or states that support distinct review questions, not temporary tool outputs that only look durable.
• Morphisms should name preserved transformations, including the places where a step is partial because one precondition, policy check, or evidence requirement might fail.
• Identity and composition matter because they expose whether a pass-through really preserves the same boundary or only looks stable until one tool, prompt, or route label changes.

Review prompts

1. Which artifact in your workflow should become its own object because the review question changes at that boundary.
2. Which transformation in your process is partial, and what missing precondition or failure path makes that partiality visible.
3. Which pass-through in your system is being treated as an identity morphism even though it actually widens scope, changes labels, or injects hidden context.

Notes and Further Reading

• Awodey’s Category Theory and Riehl’s Category Theory in Context are the right next stop if you want the formal account of objects, morphisms, identity, and associativity that this chapter only uses in engineering form.
• Fong and Spivak are the best follow-up if your practical question is how to model preserved transformations without collapsing back into implementation detail.
• Evans’s Domain-Driven Design becomes useful the moment object choice starts looking like a bounded-context or canonical-language problem instead of a purely formal one.