Software is made of inventions about what people can do.
Most of those inventions are older than the software. A few are genuinely new. Concept design is a way of telling them apart and writing each one down on its own. And because what it writes down is a course of action rather than a mechanism, the actors need not be programs at all: people, machines, and AI agents can all carry a concept out, which is why the same method now serves software, agentic AI, and the design of organizations, processes, and policies.
Maya to her project. Peter accepts. The project and .
Inviting
Offers a named person a place in a shared space and gives the invitee the final say. It refuses an answer from anyone else, and refuses any answer once the invitation has closed.
Accessing
Governs entry to a protected space. It decides for itself whether a grant is valid, and access can be withdrawn later without anything happening to the invitation.
Notifying
Carries a message to a recipient and owns what attempting delivery involves. The same behavior serves a reply to a post or an alert about a payment.
One screen presents all three at once, so it's natural to read the scene as a single feature. But each activity has its own history, its own rules about what it will refuse, and its own life in other systems. Naming them separately is what lets any one of them change without quietly changing the others.
One activity, given an account that stands on its own.
A concept is a behavior with a purpose. In outline, it needs only three things: a name, the purpose it serves, and a principle — one archetypal scenario that shows the behavior earning that purpose. The full definition then adds what the concept remembers and the actions that move it, each with the condition under which it may happen and the change it makes. It still says nothing about screens, services, or storage. Here is the first of the three above, written out as a definition.
- Purpose
-
Let an inviter offer a named person a place in a shared space while giving the invitee the final say.
Prevents: someone else answering on the invitee's behalf; a withdrawn invitation being accepted later.
- Principle
Maya invites Peter to join her project. Peter takes a day to think, then accepts. The project now has Peter's consent to admit him. Maya invites Ravi, who declines. She also invites Lee, but the project changes before he responds, so she withdraws his invitation. When Lee later tries to accept, he learns that the invitation is closed. The italicized steps are the concept's own actions; everything else is context.
- State
The invitations that have been made, and for each invitation its space, its inviter, its invitee, and whether it stands open, accepted, declined, or withdrawn. State is a summary, not a diary: it keeps just enough of what has happened to decide what may happen next.
- Actions
-
invite (inviter, invitee, space): (invitation)when there is no open invitation for this invitee and space then create a new open invitation and give it to the inviter and inviteeaccept (invitee, invitation)when this invitation is open and this is its invitee then record the acceptance and close the invitationdecline (invitee, invitation)when this invitation is open and this is its invitee then record the decline and close the invitationwithdraw (inviter, invitation)when this invitation is open and this is its inviter then close the invitation
The inviter, invitee, space, and invitation are individuals: each argument carries only an identity, never a bundle of properties. If the space had a name, some Naming activity gave it one — that history belongs to another concept.
- Design note
What gives the inviter authority to issue the invitation? The definition doesn't yet say whether the inviter must already belong to the space or present some other evidence. The question stays visible here until it's answered, rather than being settled quietly somewhere in the code.
This isn't documentation written after the fact. It's the artifact any realization can be judged against — whether the actions are API calls, steps in an office procedure, or moves made by an agent. The screen may change, the storage may move, and the surrounding application may respond differently, while the definition keeps stating what inviting has to preserve.
Most of a system is inherited. A little of it is contributed.
The shopping cart
A physical cart gives one shopper a place to gather possible purchases, keep them together while deciding, revise the selection, and buy the chosen items as a group. An online store preserves that course of action without copying the basket, the wheels, or the aisles.
Adoption isn't imitation of machinery. It's a decision about which expectations to keep. Shoppers already know a cart holds a provisional selection, so the design doesn't have to explain it.
Layering
An artist paints a figure over a sky, then decides the sky is too dark. Figure and sky are separate entries in an ordered stack, and an adjustment between them lightens the sky without rewriting its stored pixels or touching the figure.
Purpose. Let people build a rendered visual work from an ordered stack of separately represented content and transformations, revising each without rewriting the stored content of the others.
Prevents: revising one stack entry by overwriting another's source; flattening and rebuilding the work to change one contribution.
Stated that way, the invention travels. A map designer renders terrain, roads, labels, and boundaries from the same ordered stack, and changes the labels without rewriting the terrain.
An invention introduces a possibility. It becomes an innovation once people rely on it, and losing it starts to feel like a loss rather than the way things are.
The same invention survives a change of machinery.
Objects, services, database rows, and event histories are ways of realizing a system. They're a different axis from what the system lets people do. Four teams build the same invitation four ways.
All four still have to preserve the same offer, the named invitee's choice, and the rule that a closed invitation can't be answered. None of those four choices decides what inviting is for or which situations it must refuse. That's why a concept isn't a screen, a service, or a database entity, and why a table named invitations can change while the course of action stays exactly the same.
Features tangle several inventions into one smooth experience.
Ari puts a lamp in a cart, changes the quantity, and checks out. The store records an order, charges her card, and arranges delivery. One page calls that checkout. Four activities have taken place, and each can change without the others.
Adding bank transfer shouldn't change what a cart remembers. Store pickup shouldn't redefine payment. Split behavior where one part can gain new actions or new refusals without forcing the other to change, and keep it together where separating it would leave each half unable to state its own purpose.
Putting the parts back together is then a visible decision rather than a hidden one. Return to Maya and Peter. Inviting ends when it records Peter's answer. What happens next is this product's choice, written between the concepts as a reaction: a rule that says when some action occurs, where some condition holds on the states, then further actions follow.
when Inviting accepts an invitation
where the invitation is for this space
then Accessing grants the invitee entry
when Accessing grants entry to a space
then Notifying sends the new member a welcome
Another product registers an attendee instead, or opens a review space, or waits for an organizer to confirm. Each adopts the same invitation and chooses a different consequence, which is only possible because inviting never absorbed the first consequence it happened to cause. The reactions are where the domain-specific rules live — maintaining invariants, enforcing who may do what, automating the follow-ups — so the concepts themselves stay general enough to be carried to the next design.
Whatever executes the behavior — people, programs, or AI agents — the hard part is deciding what it should be.
Models write code well, and agents act tirelessly — and then both hit the same wall. Asked to work inside a real system, they change things in arbitrary places, break behavior that used to work, and fill every gap in their instructions with a guess. The common answer is to stack more agents on top with wider access. A different reading is available: those failures are exposing behavior that was never made explicit anywhere.
Behavior nobody decided
Functionality gets grouped by domain entity, so related activities end up scattered and unrelated ones conflated. Details pass through many hands — and now many agents — each filling gaps the last one left, until the system behaves in ways no single person ever chose or can even describe. Whoever is accountable has neither control over the outcome nor visibility into it.
Concepts anyone can read and write
Concepts are organized around activities and their purposes, in a language accessible to every role — and to the models themselves. Each concept holds no knowledge of the others and shares no mutable state, so a person or an agent can design, check, or implement one with only that concept in front of them, while the reactions between them carry the rules that make it this organization's system.
The result is a system whose structure corresponds to the behavior people actually care about: what you see is what it does — and whoever commissioned it keeps control of the essentials and visibility along the way. If good design gives a large improvement to today's models, it's reasonable to expect the same for the next ones, which makes design a durable multiplier rather than a temporary patch. Read the paper.
Where the argument is made in full
The Essence of Software sets out the theory with hundreds of examples from applications people use every day. It asks why so much software is still flawed, and answers by showing that a system can be read as a collection of interacting concepts. The path it lays out is meant to be usable by anyone responsible for how something works, from strategist and marketer to designer, architect, and programmer.
About the bookPrinceton University PressTutorialsCase studies
Daniel Jackson
Professor of computer science, MIT, and associate director of CSAILLead designer of the Alloy modeling language and author of Software Abstractions and The Essence of Software. Winner of the ACM SIGSOFT Impact Award and the ACM SIGSOFT Outstanding Research Award, and an ACM Fellow. He chaired a National Academies study on software dependability and has worked on software with NASA on air traffic control, with Massachusetts General Hospital on proton therapy, and with Toyota on autonomous vehicles.
Eagon Meng
PhD candidate, MIT EECSHe works on making concept design executable: a specification language for concept accounts, a pattern for expressing granular reactions, and implementations first over a graph database and more recently as a lightweight TypeScript library. His current work applies the pattern to model-generated systems, so that behavior specified once can be generated, checked, and changed one concept at a time.
Concept design comes out of the Software Design Group, which has been studying how software is designed since 1998. If you want to put it to work inside an organization, that's what collaboration is for.