Work in Progress — This appendix is not yet published.

Appendix C: The FOSM Paper — Annotated Summary

The ideas in this book rest on a single paper: “Implementing Human+AI Collaboration Using Finite Object State Machines” by Abhishek Parolkar, published at parolkar.com/fosm. This appendix is a guided walk through the paper’s arguments — condensed, annotated, and written to be accessible to non-technical readers while preserving the full weight of the technical claims.

If you have read this book, you have already absorbed most of what the paper argues. This appendix is for the moments when you need to go back to first principles, when you are explaining FOSM to a sceptic, or when you need to cite the original source in a proposal or architecture document.

1. The Problem Statement: Why CRUD Is Not Enough

The paper opens with a blunt observation: business software has not fundamentally changed its approach to data modeling in thirty years. Almost every application — from expense systems to CRMs to HR platforms — is built on the CRUD paradigm: Create, Read, Update, Delete. A database table holds records. Users edit those records. The application enforces some validation rules. That’s it.

The problem is not that CRUD is wrong. The problem is that CRUD is insufficient for modeling processes — sequences of business events that have explicit rules about what can happen, when, who is responsible, and in what order.

Consider a simple example from the paper: an invoice. In real business life, an invoice is not just a row in a database. It starts as a draft. It gets sent. It gets paid, or it becomes overdue, or it gets cancelled. Each of those transitions has rules: you cannot mark an invoice paid if it has not been sent; you cannot cancel an invoice that has already been paid. CRUD provides no native way to express these rules. The result is that developers scatter the logic across controllers, model callbacks, service objects, and database constraints — and the logic becomes impossible to reason about, audit, or change safely.

The paper identifies four concrete failure modes of the CRUD approach:

Compliance failures. When any field can be updated at any time by any authorized user, there is no enforceable record of why something changed. Auditors cannot determine whether a process was followed; they can only see the current state of the database, not the history of decisions that produced it.

Auditability gaps. CRUD systems either log nothing (common), log everything indiscriminately (expensive and noisy), or rely on developers to remember to log specific fields (error-prone). None of these approaches produces a reliable, queryable history of business decisions.

Integration tangles. When state logic is spread across multiple layers, integrating a new system — or an AI agent — requires understanding all of them. There is no single interface to say “here is what this object can do right now.”

The AI safety problem. This is the newest failure mode and the most urgent. As organizations try to give AI agents access to business systems, CRUD provides no safe boundary. An AI agent with database write access can update any field to any value at any time. There is no structural guarantee that the AI will follow the business process. The constraint has to be engineered separately, ad hoc, for every use case — which is exactly the kind of inconsistent, unaudited setup that causes incidents.

The paper’s thesis is that all four failure modes share a root cause: the absence of explicit state machines in business software. Fix that, and you fix the compliance, auditability, integration, and AI safety problems simultaneously.

2. The FOSM Formalism: A Precise Definition

The paper introduces Finite Object State Machines with a formal definition. Rendered in plain language:

A FOSM is a complete specification of a business object’s behaviour over time. It consists of six components, traditionally written as F = (S, E, G, Σ, A, T):

• S — States. A finite, enumerated set of conditions the object can be in. “Draft”, “Submitted”, “Approved”, “Rejected”. The word finite is doing real work here: the set is explicitly bounded. There is no ambiguity about which states are legal.

• E — Events. Named business actions that trigger state changes. “Submit”, “Approve”, “Reject”. Events are named from the business domain, not the technical implementation. submit is right; update_status_to_submitted is wrong.

• G — Guards. Predicates (true/false questions) evaluated before a transition is allowed to proceed. “Does the employee have sufficient leave balance?” “Has the invoice total been confirmed?” Guards enforce domain invariants — rules about the data itself — that are too nuanced to express as simple state checks.

• Σ — Side-Effects. Actions that happen as a consequence of a transition but are not themselves state changes. Sending an email, updating a counter, triggering a webhook, creating a child record. Side-effects are declared in the specification and executed after the state change is committed to the database.

• A — Actors. The set of participant types that can trigger transitions. The paper defines three: humans (authenticated users), AI agents (LLMs and automated systems), and system actors (background processes, scheduled jobs). Every transition declares which actor types are permitted to fire it.

• T — Transitions. The mapping function that takes a (current state, event) pair and returns a (next state, guard, side-effects, permitted actors) tuple. Transitions are the core artifact of the specification. If a (state, event) pair has no mapping in T, the event is illegal in that state, full stop.

The paper emphasizes the word “finite” for a specific reason. Finite means the state space is deliberately bounded. This is not a technical limitation — it is a design choice. An object that can be in an unbounded number of states is not a state machine; it is a document. The discipline of naming all states forces the designer to think through every possible condition the object can be in, which surfaces edge cases that CRUD systems typically handle inconsistently or not at all.

3. Human-AI Collaboration: The Three Actor Types

The paper’s most distinctive contribution is its treatment of AI as a first-class participant in business processes — not as an integration bolt-on, but as a structural element of the specification.

The three actor types — :human, :ai, :system — each have a natural domain of responsibility.

Humans are responsible for judgement calls: approving an expense report, deciding to promote a contact to partner, accepting a job offer. These are decisions where accountability matters, where the business wants a named person on record, and where context, relationship, and intuition play a role that automated systems cannot reliably replicate. The FOSM model surfaces these moments explicitly by restricting certain transitions to human actors only.

AI agents are responsible for pattern-matching at scale: qualifying a lead based on firmographic data, triaging a feedback ticket against existing issues, screening a job application against defined criteria. These are tasks where the inputs are large and varied, the outputs are structured, and speed and consistency matter more than individual judgement. The paper argues that FOSM makes AI deployment safe because the AI can only trigger transitions explicitly listed on its actor type. An AI agent working within the Candidate lifecycle can advance a candidate to screening; it cannot extend an offer or mark the candidate hired. That constraint is structural, not procedural — it cannot be bypassed by a poorly worded prompt.

System actors are responsible for time-based and event-driven automation: marking an invoice overdue when its due date passes, flagging inventory as low when a reorder threshold is crossed, closing a resolved inbox thread after seven days of inactivity. These transitions happen without any human or AI intervention; they are fired by background jobs that run on schedules.

The paper makes an argument that this division of labour is not just pragmatically useful — it is the right architecture for human-AI collaboration generally. The boundary is explicit, auditable, and evolvable. When you want to give AI more authority, you add its actor type to more transitions, deliberately and with full awareness of the implications. When an AI misbehaves, you can find every transition it fired in the Transition Log with a single query. There is no mystery about what happened.

“AI makes FOSM practical; FOSM makes AI safe.” — parolkar.com/fosm

This sentence, from the paper, captures the mutual dependence. Before AI, generating FOSM specifications was a bottleneck: it required a domain expert to sit down and enumerate every state, every event, every guard, every side-effect. That work took days or weeks and was rarely done completely. AI removes that bottleneck — an LLM can generate a first-cut lifecycle specification in minutes from a natural language description. But without FOSM, AI has no safe structure through which to operate in a production system. The two technologies are genuinely complementary.

4. The Transition Log as Source of Truth

The paper makes a strong claim about data architecture: the transition log is the business record. This is not a metaphor. It means the immutable history of state changes is more authoritative than the current state stored in the main record.

In a FOSM application, every state change is recorded as a row in the fosm_transitions table. The row contains: which model changed, which record, which event was fired, what state it came from, what state it moved to, who fired it (actor type and ID), when it happened, and any contextual metadata the actor provided (comments, approval notes, rejection reasons).

This produces an audit trail that is not a separate compliance feature — it is the natural output of the architecture. You do not need to remember to log state changes because state changes are log entries by definition.

The paper draws a contrast with CRUD systems. In a CRUD system, the database holds the current state of a record. If you want to know how a record arrived at its current state, you must rely on separate audit log infrastructure — a change-data-capture system, a paper trail, a updated_by column — all of which are typically incomplete and inconsistently maintained. When something goes wrong in a CRUD system, the answer to “what happened?” is often “we don’t know.”

In a FOSM system, “what happened?” has a complete, queryable answer:

SELECT event, from_state, to_state, actor_type, actor_id, metadata, created_at
FROM fosm_transitions
WHERE record_type = 'Invoice' AND record_id = 4821
ORDER BY created_at ASC;

This query returns the complete decision history of one invoice: who created it, who sent it, who recorded the payment, whether it was ever overdue, and every piece of metadata attached to each decision. No reconstruction, no inference, no gap.

The paper extends this argument to compliance. Regulatory requirements like SOX, GDPR, and ISO 27001 all require evidence that processes were followed. In a FOSM system, that evidence is built into the architecture. Compliance is not a project you undertake before an audit — it is a property of every deployment.

The paper also makes a point about the relationship between the stored state (the aasm_state column) and the transition log. The stored state is a convenience projection: it tells you where the object is right now without having to replay the log. But if there is ever a discrepancy between the stored state and what the log says should be the current state, the log is correct. The stored state can be recomputed from the log. The log cannot be reconstructed from the stored state.

5. The Three Primitives: Access Control, Inbox, and Process Documentation

The paper identifies three capabilities that recur across every FOSM-based business application and proposes that they be implemented as first-class primitives — standard components of the framework rather than one-off features.

Access Control. Every transition has an actor type list. Every actor has an identity. The framework enforces the intersection at the Transition Service layer, before guards, before database writes. This means access control is not something developers add to controllers — it is structural. An AI agent cannot trigger a human-only transition even if it has a valid API token. A human without the right role cannot approve their own expense report even if they have database access. The constraint is architectural, not procedural.

The paper recommends implementing access control as a TransitionPolicy layer that sits above the actor-type check. Actor types determine what kind of participant can fire an event; policies determine which specific participants within that type. Together, they handle the full range of real-world authorisation requirements.

Inbox/Messaging. Most business processes involve waiting. A leave request sits in :pending while the manager deliberates. An invoice sits in :sent while the customer processes payment. A candidate sits in :screening while the recruiting team reviews the application. During these waiting periods, communication happens — questions are asked, documents are exchanged, decisions are discussed. The paper argues that this communication should be attached to the FOSM record, not floating in a separate email thread or Slack channel. An embedded inbox or messaging thread, scoped to the record and visible to all relevant actors, keeps the communication auditable and associated with the state it belongs to.

Process Documentation. The paper proposes that human-readable descriptions of what each state means and what each event does should live inside the lifecycle specification, not in a separate wiki or onboarding document. This is the process_doc, doc:, and doc system described in the glossary. The motivation is simple: documentation that lives outside the code drifts; documentation that lives inside the DSL stays current because it is updated whenever the behaviour changes. The secondary benefit — that AI agents can read this documentation to understand the lifecycle and make appropriate decisions — is what elevates the feature from a documentation practice to an architectural choice.

6. The Self-Improving Loop

One of the more forward-looking sections of the paper describes a feedback mechanism it calls the self-improving loop. The idea is that the Transition Log, accumulated over time, contains everything needed to identify process inefficiencies and test improvements.

The loop works in four stages:

Bottleneck identification. Analyze the Transition Log to find states where records spend disproportionate time. If expense reports routinely sit in :submitted for ten days before being approved, that is a measurable bottleneck with a specific owner (the approver) and a specific cause (the approval process is too slow, too complex, or too low-priority).

Hypothesis formation. Based on the bottleneck data, form a specific hypothesis about how to improve the process. “If we add a second approver for amounts above $5,000, the small expenses will clear faster.” Or: “If we send a reminder to the approver after 48 hours in :submitted, average approval time will drop.”

A/B testing. Run the modified process for a subset of records and compare the outcome distributions. FOSM makes this testable because the Transition Log gives you a clean, consistent measurement of process velocity across any time period or cohort.

Continuous adaptation. Feed the results back into the lifecycle specification. Update guards, add reminder side-effects, restructure state transitions. The specification is the living document of the process.

The paper argues that AI amplifies this loop. An AI system can analyze the Transition Log at a scale no human team can match, identify non-obvious correlations between guard outcomes and downstream velocity, and suggest specific specification changes. But crucially, those suggestions are expressed as changes to the FOSM specification — they are human-reviewable, auditable, and applied deliberately, not silently written into application code.

7. Practical Implementation: The Ruby DSL and Rails

The paper describes a Ruby DSL running on Rails as the reference implementation for FOSM. This is not presented as the only possible implementation — the formalism is language-agnostic — but as the platform that most naturally supports the pattern.

The reasons are pragmatic:

Rails’ convention over configuration reduces boilerplate. The framework already provides database migrations, Active Record associations, background jobs, and a full web stack. A FOSM engine built on top of Rails inherits all of these without re-implementing them.

Ruby’s metaprogramming makes the lifecycle do...end DSL expressive and readable. The block syntax produces specifications that a non-technical stakeholder can review and verify.

Active Record provides the persistence layer for both the model state column and the fosm_transitions log, with full transactional support to ensure the two are always consistent.

Rails 8’s modern defaults — Solid Queue for background jobs, Hotwire for reactive UI, SQLite for development — mean that a FOSM application can be built and run by a very small team without specialized infrastructure.

The paper makes a specific argument about the “one-person framework” thesis: FOSM specifications are dense with information. A single lifecycle block for a moderately complex model (say, Candidate) fully specifies the business process, the access control rules, the guard invariants, the side-effect dependencies, and the process documentation. A developer who can write and read a FOSM lifecycle block can understand and modify the application with a depth that would take weeks to acquire in a traditional CRUD codebase of equivalent complexity.

“The specification bottleneck was the only thing holding state machines back.”

This is the paper’s explanation for why state machines, despite being a well-understood computer science concept, have not been widely adopted in business software. The classic objection was always: “State machines are great for simple systems, but real business processes are too complex to specify completely.” The paper inverts this. The complexity was always there — it was just hidden in undocumented controller logic and tribal knowledge. FOSM makes the complexity explicit. And now that AI can generate the specification from a natural language description, the cost of making it explicit has dropped to nearly zero.

8. Key Arguments in Summary

The paper’s core claims, stated plainly:

“AI makes FOSM practical; FOSM makes AI safe.”
AI removes the specification bottleneck that made state machines impractical to adopt at scale. State machines provide the structural boundaries that make AI safe to deploy in production business systems. Neither is sufficient alone; together they are powerful.

“The specification bottleneck was the only thing holding state machines back.”
For decades, the objection to state machines was that specifying them was too expensive. AI eliminates that cost. There is now no good reason to build a business process on CRUD when FOSM is available.

“The transition log IS the business record.”
Not a backup, not a compliance audit trail, not a debugging aid. The primary, authoritative record of what happened to a business object over time. Everything else — dashboards, reports, stored states — is a projection of the log.

“Bounded contexts give AI safe operating space.”
An AI agent confined to a FOSM lifecycle has a well-defined, auditable action space. It can do exactly what the specification allows and nothing more. This is the right architecture for human-AI collaboration: not AI with maximum access and procedural guardrails, but AI with structural constraints that are impossible to accidentally bypass.

“Compliance is an architectural property, not a project.”
In a FOSM application, every state change is audited by design. There is no compliance sprint before a SOX audit; the audit trail is complete and accurate as a side-effect of normal operation.

The full paper is available at parolkar.com/fosm. It is approximately a thirty-minute read and rewards a second pass once you have built your first lifecycle.