Vocabulary
What does 'cart' mean in this application? Business language (ubiquitous language), placed in a form readable by both humans and machines.
Semantic SSOT
Place meaning in one place.
Code has become cheap. But meaning—'what should be built'—remains expensive. The same business fact gets copied into specs, code, tests, DB constraints, and FAQs—in separate dialects every time. ALPS is a small specification that writes only that meaning. BEAR.Sunday projects implementation, documentation, and AI instruments from here.
The thin waist
The wasp waist. Many entrances, many exits, connected at a single point.
Naively connecting sources (stories, legacy code, domain) to artifacts (diagrams, schemas, code, instruments) yields N×M combinations. Pass through a single waist of pure meaning in between, and it collapses to N+M—all transformations converge at a single point. Same shape as IP for the Internet, LLVM IR for compilers. ALPS is the waist for "application meaning."
N sources
user stories ・ legacy code ・ domain ・ requirements
converge ↓
ALPS — wasp waist / thin waist
SSOT of meaning
vocabulary ・ states ・ transitions (safe・idempotent・unsafe)
project ↓
M projections
Diagrams ・ OpenAPI ・ JSON Schema ・ llms.txt ・ Fakes ・ Tests ・ Code ・ MCP/Tool ・ Hypermedia
Naive connection: N×M. One waist: N+M.
What ALPS writes (and won't)
Only vocabulary, states, and transitions. Deliberately boring.
ALPS (Application-Level Profile Semantics) is a small specification born from the lineage of REST and hypermedia design, by Amundsen et al. It can write essentially three things. Intentionally boring, and that boredom is designed.
{ "id": "Cart", "type": "semantic", "title": "Shopping Cart",
"tag": "flow-checkout",
"descriptor": [{ "href": "#doAddItem" }] },
{ "id": "doAddItem", "type": "unsafe", "rt": "#Cart",
"doc": "Add an item to the cart" }Which table it's saved to, which screen it appears on—none of that is written. There's no place to write it.
States
What states does the application have? Not screens—states as meaning.
Transitions and their nature
Transitions between states, and whether each is safe (observation only), idempotent (same result when repeated), or unsafe (irreversible change). REST semantics directly become the vocabulary.
What it can't write = what it doesn't compete with
It can't describe screen layouts, persistence methods, or performance requirements. Precisely because it can't, it competes with no artifact and becomes a shared conduit. The list of things it can't write is the design of ALPS.
Projection & tags
One model, three queries.
Each descriptor can carry free tags. flow-checkout for checkout flows, actor-guest for guest-allowed operations, src-legacy for legacy-derived concepts. Then "a state transition diagram for checkout only" or "the system as seen by guests" aren't newly authored documents—they're projection queries against the same model.
The diagram for sales, the diagram for security review, the diagram for migration planning—these aren't three separate documents but three queries against one model. "One model, many views"—because only meaning goes into the model and the rest is left to projection, the model stays small and governable by humans.
Three doors
One model, three doors.
If meaning resides in one place, how does each role access it? The answer: through different protocols for different phases.
Design — MCP
AI agents query, verify, and edit. Rather than passing the entire document, ask 'What transitions are available from this state?' and receive only the 200 needed tokens. Don't read about the model—converse with it.
Edit — LSP
Humans touch the same intelligence. Broken references are warned on the spot; concept renames cascade to all references. From intent expression to meaning confirmation, syntax as an intermediary disappears.
Execute — Hypermedia
The running application itself carries semantically structured responses. Agents operating in production ground themselves in the same meaning model that designed the system.
The reader arrived
The reader HATEOAS was waiting for has just arrived.
When HATEOAS was formalized in 2000, it envisioned "machine clients" that could read meaning and autonomously choose the next transition. That reader didn't appear for over twenty years. Humans needed UIs; machines were too dumb.
That reader has now arrived—and through the very same technology that made code cheap. Large language models are both the force that turned meaning drift into a crisis, and simultaneously the reader that finally makes keeping meaning machine-readable a worthwhile investment. The crisis and the conditions for its solution arrived together, carried by the same technology.
Where BEAR sits
BEAR.Sunday sits on the projection side of the waist.
BEAR.Sunday's strength is the lower half—projection. From ResourceObjects come HAL and hypermedia (runtime), ApiDoc, OpenAPI, JSON Schema, llms.txt (documentation), and ToolUse/MCP (AI instruments). With ALPS as the SSOT, code, documentation, and tools are all projected from the same meaning— implementation and docs don't drift apart. You can even prove in CI that "there is no gap."
Rather than absorbing meaning and rebuilding it, you place it at the waist as an independent standard and connect to it. This is the culmination of "don't absorb—connect." The work of excavating meaning itself (the upper half) is the job of ALPS and its dedicated tools.
App State Diagram →
A tool that draws state transition diagrams from ALPS, used to excavate and project meaning. Proof of "meaning as intermediate representation" lives here.
ALPS Spec →
The official specification of Application-Level Profile Semantics. A minimal grammar of vocabulary, states, and transitions.
Back to AI Era value →
How resources become AI instruments as-is, and REST semantics as a safety model.
Start with one resource