Summary: A retrieval-augmented generation chunk retrieves text that resembles the question asked. It does not tell an agent who must act, on what, under which conditions, or why. A process atom is a different kind of object entirely, a governed, versioned, evidence-bound unit that captures exactly one organisational rule and refuses to answer when its own scope is unclear. This piece reconstructs the architecture that makes that possible, and the single failure mode that makes it necessary.
In brief: Enterprise agents increasingly retrieve from policy documents to decide what they are allowed to do. Treating that retrieval as a semantic-similarity problem, the standard RAG approach, produces answers that sound right and are structurally unable to say when they might be wrong. A recently published architecture for organisational memory proposes the alternative: a twelve-component atom object, a formal applicability predicate, and a fourteen-stage compilation pipeline from raw policy document to governed, machine-readable rule. This piece reconstructs that architecture, states the one safeguard the original research identifies as most critical, and sets out what a technically complete enterprise implementation actually requires.
In This Article:
- The problem: a text chunk cannot tell an agent when it applies
- The solution: the process atom as a governed policy object
- The single most important safeguard, and the failure it prevents
- How an atom actually gets built: a fourteen-stage pipeline
- Governance: what stops two atoms from silently contradicting each other
- The vision: organisational memory that outlives any one AI tool
The problem: a text chunk cannot tell an agent when it applies
Standard retrieval-augmented generation treats organisational knowledge as passages of text selected because they resemble a query, and that resemblance is precisely the wrong signal for enterprise policy, where what matters is not similarity but applicability. A RAG chunk says, in effect, here is some potentially relevant text. It does not say when this rule applies, to whom, under which conditions, or what happens if it is violated.
An agent deciding whether a purchase requisition needs a cost centre, whether a deviation requires compliance sign-off, or whether a supplier is currently approved needs a structured answer, not a plausible-sounding passage. Semantic similarity can retrieve a rule that mentions the right words while missing the one detail, a section heading, a jurisdiction, an exception clause, that actually determines whether it applies to the case in front of the agent.
Recently published research on organisational memory for agentic systems proposes a different unit entirely: the process atom, a self-contained object that captures exactly one rule, constraint, or responsibility, separating the conditions under which it applies from the behaviour it requires and the reason that behaviour exists. Reported results found atom-based memory outperforming a conventional RAG baseline on process-execution tasks. This piece reconstructs the fuller architecture that idea implies, since the original research explicitly stops short of describing its own extraction implementation, and works through what a technically complete version would actually require.
The solution: the process atom as a governed policy object
A process atom is best understood as a compiled, executable unit of organisational policy, closer to a governed configuration item than to a passage of retrieved text. The minimal definition covers a name, a source reference, structured content, and a set of domain tags. For an operational enterprise system, that minimal structure needs extending into a twelve-component object covering everything a real deployment requires: identity, versioning, conflict resolution, provenance, and reuse across multiple agents.
| Component | What it captures |
|---|---|
| Identity | A stable identifier independent of the atom's exact wording |
| Version | Lifecycle state: candidate, under review, approved, active, superseded, withdrawn |
| Knowledge type | The rule's normative category, obligation, prohibition, exception, and so on |
| Provenance | Source document, page, section, and the exact evidence text |
| Applicability | An executable predicate stating precisely when the rule applies |
| Action | The required behaviour, expressed as a structured, executable statement |
| Purpose | The business rationale, explanatory only, never expanding scope |
| Domain grounding | Tags linking the atom to processes, roles, and business objects |
| Governance | Owner, approval authority, and review status |
| Relationships | Links to other atoms: specialises, conflicts with, supersedes, and similar |
| Retrieval representations | The forms in which the atom can actually be found and matched |
| Extraction metadata | Which model, parser, and prompt version produced this atom, and when |
Identity cannot simply be a hash of the text, because wording can improve without the underlying rule changing, and an old version may still need to remain available for audit long after a newer one takes effect. A defensible lifecycle needs to move an atom through candidate, review, approval, activation, and eventual supersession as a tracked state, not an implicit assumption. Ten distinct knowledge types, obligation, prohibition, permission, responsibility, decision rule, data requirement, escalation, sequence, temporal rule, and exception, matter because a system that cannot tell an obligation from a permission cannot reliably detect when two rules actually conflict.
The single most important safeguard, and the failure it prevents
The one architectural requirement that matters more than any other is that applicability must be evidence-bound and uncertainty-aware: unknown scope must never silently become universal scope.
Consider a rule that reads, in full, "all deviations must be reviewed by Compliance," sitting under a heading that says "7.2 Medical Equipment Purchases." Read as plain text, the rule looks universal. Read with its heading intact, it applies to one narrow category. An extractor that drops the heading during processing produces an atom that looks correct, passes validation, and quietly enforces a compliance requirement on categories of purchase it was never meant to touch. That precise failure pattern, an applicability scope extracted too broadly, is the reported cause of error in the original research's own results.
The fix is a discipline, not a feature: a missing subsidiary restriction gets recorded as not stated, requires review true, rather than silently defaulting to applies everywhere. Every dimension of applicability carries its own evidence, the exact page, section, and quoted text it came from, so a human reviewer can tell the difference between a condition that was explicitly stated, one that was reasonably inferred from context, and one the extractor simply invented. An unsupported field blocks publication outright. Getting this one discipline wrong is what turns a governed memory system into an ungoverned one.
How an atom actually gets built: a fourteen-stage pipeline
Producing a governed atom from a raw policy document is not a single model call. It is a fourteen-stage compilation pipeline running from source registration through layout-aware parsing, atomic decomposition, provenance binding, conflict analysis, and human-governed publication. Each stage exists to catch a specific failure the earlier stages cannot.
in fig. From raw policy document to governed atom: fourteen stages, four of them specifically defending against silent scope over-extension.
Layout-aware parsing matters more than it sounds. Plain-text extraction loses page numbers, headings, table structure, and footnotes, exactly the elements that can restrict an otherwise universal-looking sentence to a specific category, region, or exception. A document's own heading hierarchy is not decoration. It is often where the actual scope of a rule lives.
Atomic decomposition asks a subtle question: what counts as one rule. A useful test is whether a behavioural requirement can be independently retrieved, approved, changed, superseded, or violated. "Every purchase requisition must have a cost centre, and every capital purchase must include an asset class" is two atoms, because the two obligations can change independently. "Every requisition must have a cost centre; requisitions without one must be rejected" is one atom, because the rejection is simply the enforcement consequence of the same requirement, not a separate rule. Getting this boundary wrong in either direction breaks the system: fragments too large become impossible to compare or update individually, fragments too small lose the business meaning a domain expert actually needs.
Later stages compare each newly extracted atom against existing organisational memory before anything publishes, proposing an addition, a modification, a removal, no change, or a flag for human conflict review. Nothing reaches production without a person approving it.
Governance: what stops two atoms from silently contradicting each other
Two atoms can overlap in scope without conflicting, or they can conflict outright, and telling the two apart requires a formal test, not a gut check. Two rules scoped to the same medical-equipment purchase might both legitimately apply, one requiring a cost centre, one requiring compliance approval, without contradicting each other. Two rules that both apply to the same case but demand incompatible actions, one requiring approval, one prohibiting it, are a genuine conflict that needs resolution before either can safely execute.
| Knowledge type | What it means |
|---|---|
| Obligation | Something must be done |
| Prohibition | Something must not be done |
| Permission | Something may be done |
| Responsibility | A role owns or performs something |
| Decision rule | A condition determines an outcome |
| Data requirement | A field or piece of evidence is mandatory |
| Escalation | A case must be transferred or reviewed |
| Sequence | One activity must precede another |
| Temporal rule | Something must happen within a defined period |
| Exception | A general rule is overridden under specific conditions |
Resolving an actual conflict cannot rest on semantic similarity alone. It needs authority metadata: which source carries more weight, which rule is more specific, which one has an explicit exception relationship to the other, who owns each policy, and whether the conflicting rule is regulatory or purely internal. There is no universal rule such as policy always overrides procedure; that precedence has to be encoded deliberately by the organisation itself, and every resolution should record who approved it and why.
Four validation layers stand between a freshly extracted atom and anything a live agent can actually rely on: schema validation confirming every required field is present and well-formed, semantic completeness confirming the atom actually answers who, what, when, and under what condition, atomicity validation catching rules that quietly bundle multiple independent obligations together, and groundedness validation confirming every claim is labelled explicit, inferred, or unsupported, with unsupported fields blocking publication outright rather than passing through as a plausible guess.
The vision: organisational memory that outlives any one AI tool
A governed atom is valuable specifically because it survives the AI tool that happens to be reading it today, which is the property a RAG chunk never had. A chunk exists to answer one query well. An atom exists as a durable, versioned record of what the organisation's own rules actually mean, retrievable, explainable, comparable, and auditable regardless of which model or which agent framework consumes it next.
That durability changes what building this kind of system is actually for. It is not a retrieval optimisation exercise. It is capturing institutional knowledge, in a form a machine can act on safely, before the person who understands the nuance behind a policy leaves the organisation and takes that context with them.
The deepest defensible definition of a process atom, stated plainly: a versioned, source-grounded, human-governed policy object that expresses one independently governable organisational behaviour as an applicability predicate and a normative action, together with its rationale, provenance, authority, relationships, and retrieval representations. It is the smallest governed unit at which organisational behaviour can be retrieved, explained, compared, changed, approved, tested, and reused across every agent that needs it, not just the one that happens to be running today.
If your organisation is building agentic systems on top of policy documents your RAG pipeline treats as plain text, talk to Tarento's Generative & Agentic AI practice about what a governed process-atom layer would take to build on your own policy estate.
