# BLOM — Boundary Layer Operating Model
Date: 2026-10-30
Version: 1.10
BLOM connects a desired outcome to the decisions and standards that govern it, the work that
changes the product, and the evidence supporting each completion claim. The product is held as
**items** in a [hierarchy](#1-hierarchy), and **tasks** track the work on it: a Job creates,
changes, or retires items, or changes none, and a report, such as a Bug, records and assesses what
it concerns and reaches further work only through a Job that takes it on
([How work changes items](#how-work-changes-items)).
**An initiative is a group of Jobs. A Job can have sub-jobs, and each sub-job is itself a Job.**
Initiatives group work toward an intended outcome; parent and sub-job links divide a Job's work
into separately tracked scopes ([Jobs and sub-jobs](#jobs-and-sub-jobs)). These are foundational
work relationships, distinct from the hierarchy of product items.
Every handoff preserves what is known, what is authorized, and what remains unresolved.
### The relationships at a glance
```mermaid
flowchart LR
O[Organization or Team] -->|owns| P[Product: the top item]
P --> I[Lower items at configured levels]
B[Report: Bug, Issue, Feedback, Change request] -->|concerns| I
B -->|taken on by| J[Job]
N[Initiative] --> J
J --> SJ[Sub-job: also a Job]
J -->|targets| I
J -->|records| PV[PDLC version]
PV -->|pins| S[Its definition and component standards]
T[Other standards] -->|apply by applicability| J
I --> D[Specs, ADRs, and plans, by revision]
J -->|uses| D
J --> R[Reviews and other evidence]
L[Release] -->|carries work from| J
L -->|makes| V[Item versions]
I --> V
```
Hierarchy, initiative membership, and Job parentage are different relationships. Item links may
name the Product itself as well as lower items. A report records and assesses; only a Job carries
the resulting work. Standards apply by their rules, not item placement. Releases record what was
delivered; Reviews and evidence support conclusions about exact subjects. Links grant no authority.
**BLOM defines the facts that must remain distinguishable. Each organization
defines the process used to produce, approve, and verify those facts.**
The BLOM method is the operating model; BLOM, the product, supports it. This document owns the
core definitions and the seven-part reading path. Its supporting guides own the detailed
procedures and remain part of BLOM:
| Supporting guide | Use it for |
| --- | --- |
| Process and Gates | Configure, approve, publish, and change a process; apply roles, gates, exceptions, and corrective routes. |
| Delivery and Evidence | Plan verification and release, evaluate evidence, track environments, resolve gaps, and hand work between people and agents. |
| Design Lab | Explore front-end prototypes, reuse optional micro apps, review designs, and carry them into delivery. |
The [core distinctions](#core-distinctions),
[core terms](#core-terms), and [results](#results) below apply in every section and guide.
## Core distinctions
BLOM keeps these facts distinguishable in every setup. Sections and guides apply them rather
than restate them.
1. **Intent and observation.** Intent describes the desired outcome; an observation describes
what appears to exist. Observing behavior never approves it.
2. **Draft and approval.** A draft is not approved authority. An approval names a revision,
purpose, and scope; approving one purpose, such as build, does not approve another, such as
release.
3. **Delivery facts.** Implementation, verification, integration, deployment, and user exposure
are separate facts. A merged PR establishes integration to its target only, and a deployment
does not establish exposure.
4. **Claims and evidence.** A claim, a submitted attachment, and evidence that satisfies a
requirement are different things. An agent's completion statement is a claim until evidence
supports it.
5. **Results.** Not applicable, failed, missing, stale, unknown, and excepted keep their meanings
and never count as satisfied; see [Results](#results).
6. **Labels grant nothing.** A phase name, activity state, priority, urgency, source label,
checkout, assignment, dependency link, or document type grants no permission, approval,
or exception, and waives no requirement.
7. **Finishing is not completing.** A closed session, returned checkout, finished assessment, or
completed next action does not by itself complete the task, verify behavior, or release
anything. Completing a task establishes that its completion criteria were met, not that its
intended outcome happened.
8. **Plans are not results.** A V-Plan or R-Plan, or an approval of one, does not establish that
its checks ran or its release happened. Actual results are recorded separately.
9. **Exceptions, departures, and overrides are not passes.** Each is recorded with its authority
or reason and stays visible at closure.
10. **Prototypes.** A prototype can establish a reviewed design direction, not implemented or
production-verified behavior. Its evidence covers only what was explored or checked.
11. **History.** Process, spec, and structure changes preserve the rules, approvals, and evidence
that governed earlier work. Corrections add new records and never rewrite old ones; see the
[Audit Layer](#7-audit-layer).
12. **Proportionality.** These distinctions don't require every team to approve every change or
run every kind of check; they require BLOM, the product, to describe the actual situation accurately. A
decision that approval is unnecessary is recorded as approval not required, never as approved.
13. **Items and work.** An item holds durable knowledge of what the product is and is meant to be;
a task is a body of work. A Job creates, changes, or retires items or, like an investigation or
a verification, changes none; a report, such as a Bug, records the items it concerns without
changing them ([Task types](#task-types)). Tasks close, and the items they changed remain, with
the record of each change ([How work changes items](#how-work-changes-items)).
14. **Work grouping and decomposition.** An initiative groups Jobs. A Job can have sub-jobs,
each a Job with its own scope, owner, and completion criteria. Initiative membership and
parentage are separate relationships; neither replaces product hierarchy, creates a dependency,
grants authority, or proves completion ([Jobs and sub-jobs](#jobs-and-sub-jobs)).
## Core terms
Hierarchy levels are defined in [Hierarchy](#hierarchy-definitions), standards in
[Standards](#3-standards), and the other document types in [Specs](#4-specs).
| Term | Meaning |
| --- | --- |
| Approval | Authorization of a particular revision for a stated purpose and scope, granted by passing the gate check configured for it. |
| Gate check | The configured check for a phase move or another controlled action: sign-off by an eligible person or authorized identified agent, an automated check, or a configured combination. Passing it grants the scoped approval; enforcement (observe, warn, or block) decides whether an unmet check stops the move. |
| Evidence | Attributable information, with its subject revision, source, and time, that supports or contradicts a named criterion or requirement. |
| Review | A document recording an assessment of exact subjects, with reviewer, time, independence, verdict, and findings, attached to a Job. It is evidence, not approval; see [Reviews](#reviews). |
| Exception | A separately authorized, bounded deviation from an applicable requirement, granted by the rule's owner where the rule permits it. |
| Departure | A recorded deviation from an applicable requirement or rule. From a Mandatory one it needs an exception; from an Advisory one it records its reason, never satisfies it, and leaves its unmet result visible. A document records its own departures in its text; work records them on the task; see [Standards](#3-standards). |
| Strength | How binding a requirement or rule is: Mandatory, Advisory, or informational, defined in [Standards](#3-standards). Only a Mandatory requirement can be a blocking requirement. |
| Override | A recorded replacement of a next action that isn't done, with the actor, reason, and authority; the replaced action shows as Overridden, never as Done. Also, for an open company rule, an authorized project decision that changes which rule applies, recorded with who, when, and why; a locked rule can't be overridden (Process and Gates). |
| Gap | A visible difference or missing information, classified by whether action is needed. |
| Decision | An attributed choice with its scope, rationale, basis, status, supersession, and application links; see [Decision records](#decision-records). It is not automatically an approval. Accepting an ADR is an approval with the purpose Accept. |
| Item | A Product, or a thing at a configured level below it, such as a Capability, Feature, or Component: what specs, ADRs, and plans belong to and Jobs change. Each item sits at a node, its place in the hierarchy ([Hierarchy](#1-hierarchy)). |
| Item version | The identified state of an item made by a release, recording its number, release basis, and carried Jobs. It is distinct from a document revision and an In work projection; see [Item versions](#item-versions). |
| Document revision | An identified content revision of a spec, standard, ADR, or plan. Its approval and evidence bind its exact content, not an item's mutable progress or projected version number. |
| Release | The recorded move of an identified candidate across the configured production boundary. A successful release makes the item versions it delivered; a failed or partial attempt makes none and takes no number. A rollback preserves the released version and changes observations. |
| Release candidate | The exact code, document revisions, migrations, and other artifacts proposed for a release. A candidate can fail validation or never ship. |
| Document set | The specs, ADRs, and plans that define or govern one item: those homed at it, those its own documents cite as governing references, and those whose recorded scope names it. It is derived from document homes and references and has no approval of its own; see [Document sets](#document-sets). |
| Process profile | The workflow for a declared scope, expressed as a named PDLC with identified versions: phases, action types, gates, roles, requirements, completion rules, and exact pins to its definition standard and component guidance. Work records the approved PDLC version it follows; see [Customization and gates](#customization-and-gates). |
| Action type | A configured kind of step, such as Code, Claude review, or Human approval. It defines who can perform it (a person, a role, or an AI agent; never an automation), what counts as done, its outcomes, and who besides the work owner may replace it before it is done. |
| Next action | The typed step an open task is currently waiting on, or blank: a step of the task, never a task itself. Whoever finished the task's last action, or opened the task, suggests it, or the work owner or anyone the profile permits sets it when it is blank; the work owner can replace it, and no task's actions are planned ahead. |
| Task | A tracked Job or report, with identity, primary product home, owner, assignee, brief, and recorded progress or disposition; see [Task types](#task-types). |
| Report | A task that records and assesses a Bug, Issue, Feedback, or Change request concerning items, documents, standards, or process; assessment is separate from delivery. |
| Takes on | An attributed link from a Job to a report whose resulting work its brief covers. Several reports may link to one Job and one report to several Jobs; the link proves neither resolution, delivery, nor approval. |
| Job | A task that carries a defined piece of work, from investigation or planning through delivery as its scope requires. It may have sub-jobs and retains its own promised result and completion criteria. |
| Sub-job | A Job with one explicit parent Job; it retains its own identity, scope, owner, assignee, process, and criteria. Depth is configured; BLOM, the product, allows three Job levels in its MVP. See [Jobs and sub-jobs](#jobs-and-sub-jobs). |
| Initiative | A named group of Jobs, including sub-jobs in it, toward an outcome, with its own brief and criteria. [Ownership and outcomes](#ownership-and-outcomes) defines membership and defaults; it is not a hierarchy level or primary home. |
| Work list | A view showing every task on one line with its key fields. It is derived from the tasks, never a second record. |
| Work brief | Versioned fields on a task: desired outcome, scope, including a Job's target items or the items a report concerns, completion criteria, governing references, and evidence expectations. |
| Assignment | The record of a task's one current assignee, a person or identified agent, retained across steps until reassigned or unassigned. It is a notice of responsibility, not a lease or permission; see [Assignment and active work](#assignment-and-active-work). |
| Checkout | A record that a named person or agent is actively using or revising an exact document revision, and why, linked to its execution and declared scope. It is not a Git operation or a permission. |
| Step contribution | A bounded part of a step performed and recorded by a named actor without holding the task assignment. Its scope is its execution's declared scope; it is not a separate brief or Job. |
| Active work | An attributed execution of a step or bounded part of it, with declared scope, workspace, progress, and end or handoff. Several executions can support one task without adding assignees. |
| Overlap rule | The configured response when declared active work overlaps on a resource: allow, warn, coordinate, or exclusive. Task reassignment does not itself clear a resource conflict. |
| Handoff | The context and current work state passed between actors, including the revisions supplied. |
| Session close | A record of what an actor completed, attempted, verified, and left unresolved. |
| Baseline | The approved production intent that an item is compared against; undeclared until an authorized owner declares it. |
| Audit trail | The linked, append-only records that show who changed what, why, how, under what authority and evidence, where it shipped, and what remains unresolved. |
### Results
Every Mandatory or Advisory requirement is evaluated in three layers; an informational one is
shown, never evaluated ([Standards](#3-standards)). Gates, dependencies, and summaries read the
requirement result.
| Layer | Values |
| --- | --- |
| Applicability | Applies, or Not applicable with its basis recorded. Decided before evaluation; a requirement whose applicability hasn't been decided applies, and Not applicable is recorded, never assumed. |
| Evidence item | Passed, Failed, or Inconclusive, each with its subject revision, source, and time. An evidence item is current, stale (no longer sufficient to establish the current claim, for example because its subject or the requirement changed or it aged past its freshness window), or superseded. |
| Requirement result | **Satisfied**. **Not satisfied**: failed, missing, or stale. **Unknown**: the available information can't establish the result, for example because the source is unavailable or the evidence conflicts or is inconclusive. **Excepted**: covered by a valid scoped exception. |
Summaries count every category, for example *6 required: 3 satisfied · 1 failed · 1 excepted ·
1 unknown (CI unreachable)*. The
Delivery and Evidence guide defines
how each reason is determined.
A summary states its scope and whether its inputs are complete. Missing, inaccessible, or
partially read records cannot establish zero work, no failures, or total completion.
## 1. Hierarchy
**Organization → Team (optional) → Product → Capability → Feature → Component**
A Product, and each thing at a configured level below it, such as a Capability, Feature, or
Component, is an **item**, the thing specs, ADRs, and plans belong to and Jobs change;
Organization and Team are ownership and policy scopes above the items. Each item sits at a
**node**, its place in the hierarchy, with its parent and, where the firm numbers them, its
number: *item* names the thing, and *node* only its place.
Every customer has **Organization** and **Product**, which can't be removed. **Team** is optional
between them: each product belongs either to its organization directly or to one team within it,
and a firm can have both kinds. None of the three can be reordered or replaced by a custom level, and Team is the
only level between Organization and Product: teams don't nest. A firm can rename the Team level
for all its teams, for example to Group, Department, or Division; the label changes no identity,
ownership, membership, permission, or rule.
Apart from renaming Team, customization begins below Product: the lower levels can be renamed,
added, omitted, or reordered, with explicit permitted parent/child relationships. Six is the
default depth, not a limit; there is no fixed method limit on the additional levels a firm can
define.
| Setup | Work-group hierarchy | Intended use |
| --- | --- | --- |
| Default | Organization → Team → Product → Capability → Feature → Component | Organize product knowledge from enduring abilities to behavior and supporting parts, with each product owned by a team. |
| Minimum | Organization → Product | Start work directly on a product the organization owns, without a team or lower-level records. |
| Custom example | Organization → Department → Product → Product Area → Feature → Component | Rename Team to Department, add Product Area, and omit Capability while retaining the required Organization and Product. |
### Hierarchy definitions
| Level or grouping | Meaning |
| --- | --- |
| Organization | The account and organization-policy boundary that owns membership and shared rules, and directly owns each product no team owns. |
| Team | An optional ownership group within the organization: it owns the products assigned to it, and it may consist of one person. A firm can rename the level, for example to Group, Department, or Division. |
| Product | A durable system or offering with one owning scope, its organization or one team within it, and a named accountable owner, who is a person; its intent, observed behavior, and gaps survive individual delivery efforts. |
| Capability | A durable ability of the product, such as member onboarding. |
| Feature | A coherent behavior or experience, such as inviting a member by email. |
| Component | A functional or technical part supporting features, such as invitation delivery; it need not be a UI element, service, or deployable unit. |
| Initiative | A delivery grouping, not a hierarchy level; see [Ownership and outcomes](#ownership-and-outcomes) for its brief, membership, and defaults. |
| Project | A customer-facing name for an Initiative, not another required level. |
An item's [document set](#document-sets) holds the documents homed at it and the documents
elsewhere that govern it. The item exists without any document, and a document never creates,
moves, or reorders a node. An item is active until work retires it
([How work changes items](#how-work-changes-items)). Organization and Team
own people and policy; their standards govern items by applicability, which placement alone
doesn't decide ([Standards](#3-standards)).
### Ownership and outcomes
Each team belongs to one organization. People can belong to several teams. Each product has
exactly one **owning scope**, its organization or one team within it, and a named accountable
owner, who is a person. Other teams can contribute to a product without becoming its owner. A
team's process profiles cover new work homed in the products it owns, and the organization's
cover new work homed in the products it owns directly; open work keeps the version it recorded,
even after a transfer. The organization's profile isn't a company rule and covers no new work on
a team's products; company rules are the organization rules that bind every product
(Company rules). For a
product the organization owns directly, its accountable owner takes any part BLOM gives a
product's owning team, such as agreeing to coordinated work. Every item has one place in the
hierarchy, and every task has one primary home: a Product or a lower item.
Each configured group identifies its responsible owner and whether it represents durable product
knowledge, a delivery outcome, or coordination; a custom label does not change those meanings.
Organization roots have no parent, and containment cannot have cycles. Contribution, usage,
and dependency links are not extra parents and do not grant access. Shared components and work
retain one identity and primary owner across the scopes that reference them. Requirements from
other affected products still apply; placement alone does not determine policy applicability.
Different products may configure different lower levels without losing the required foundation.
An **initiative is a group of Jobs** toward an outcome; customers may call it a project.
Its brief names outcome, users, scope, exclusions, accountable owner, criteria, environment/audience,
and Jobs with their target items. Link governing revisions, dependencies, milestones, risks, and
evidence. Specs and initiatives may relate many-to-many through Jobs. Membership changes no
hierarchy home, owning scope, or access; only its project rules
apply through that membership.
Every Job, including a sub-job, belongs to exactly one initiative, and for now an initiative
stays within one product: its open Jobs are homed in that product. A closed Job keeps its closing
initiative as history after a later item move; reopening reconciles its current home, initiative,
and parent/sub-job relationships before work resumes. A Job homed there may still change items in another
product, whose requirements still apply ([How work changes items](#how-work-changes-items)), and an
outcome that needs work homed in several products gets an initiative in each, with dependencies
between their Jobs where one needs another's result. Each product has a **Backlog** initiative, and
a Job opened without a parent or chosen initiative goes to its product's default initiative:
Backlog, unless the product names another, such as MVP. A sub-job instead takes its parent's
initiative; a conflicting initiative choice is refused, not replaced by the product default.
Moving a Job to another initiative is an ordinary recorded
edit. Initiatives can be renamed, Backlog included, and can't be turned off as a feature, since
every Job is in one. Reports, such as Bugs, Issues, and Feedback, need no initiative: they
reach work only when a Job takes them on. The Backlog
initiative is a group, not the Backlog activity state: a Job in it can be Active, and a Job in any
initiative can show as Backlog ([Task state](#task-state)). A product plans its work with named
initiatives, such as MVP and Post-MVP. Each item shows, for each initiative, how far that initiative's open Jobs
targeting it have got, by PDLC phase, and a capability rolls up its features the same way. The
phase shows beside the item's approved, verified, integrated, deployed, and exposed facts, never in
place of them. Where an initiative has no open Job on an item, the item shows "no work linked" for
it, never a phase.
Summaries separate spec coverage/authority, delivery, verification, and release/exposure. Count
each canonical item once in primary totals and label contribution views separately. Show retired
items apart from active ones. Identify whether summaries use current or historical placement.
BLOM keeps no measured outcome as a built-in fact: an initiative has no outcome criteria results,
outcome state, outcome view, or outcome column. A firm that wants to measure something runs a
Job, records the result on it, and links it to the initiative. Neither closing all of an
initiative's Jobs nor an average progress score shows that its intended outcome happened
([core distinction 7](#core-distinctions)), and removing work its completion criteria require
never silently completes an initiative. Product knowledge, evidence, owners, and unresolved
obligations remain after an initiative closes.
Record initiative membership and every change. Moving a parent moves its open descendants with
it, each recorded; moving a linked sub-job alone is refused. Open parent/child links share the
initiative and product home. Closed Jobs retain their closing initiative as history, including
closed children of a moving parent; historical membership does not create current membership in
the new group. Reopening reconciles home, initiative, and parent links together. Count each member
once; parent progress is a summary, not another copy of its children's work.
Reorganization preserves identities, prior placement, and governing history. Preview and reassess
changes to ownership, permissions, process applicability, and policy; moving a record does not
approve it or restart its lifecycle. Teams can come later: creating a team changes no existing
product or work, and a product can be transferred into, out of, or between teams without losing
its identity, its history, or its open work's recorded process versions. See the
reorganization procedure.
### Item versions
An item keeps its identity as its intent and implementation change. A **successful release creates its
recorded item version**, fixing the version number at release time and linking the release basis
and carried work. Jobs target items; **Jobs do not choose versions**.
**In work** is a mutable projection shown once work starts, based on the chosen initiative
target. If another release happens first, the projected number can move. It is not an immutable
revision to approve or cite as proof of what shipped. An initiative may optionally declare a
specific version target or a +1 increment; that is planning intent, not a released version.
Preserve a released version's identity, display number, base, label where used, exact release
subjects, and history. One release can carry several Jobs; its record links their exact work and
versions, whichever Job holds the Release step. Record its integration boundary and destination. Each
profile identifies its integration and production boundaries explicitly.
Document revisions identify text; release candidates
identify proposed artifacts; released item versions record what a release made. Work that changes
no item need not create a version. The release procedure
owns provenance, release scope, and In Prod assertions versus observations.
An In Prod assertion retains its actor, time, basis, and links to the released version and actual
artifact or deployment evidence. It cannot turn an unknown or conflicting environment observation
into a verified production fact.
## 2. PDLC
### Recommended BLOM lifecycle
The recommended starter is **Define → Design & Specify → Build → Verify → Release**. Customers
can add, combine, rename, reorder, or replace phases and add steps within them. Five is the
starting layout, not a phase limit. This starter is named Recommended
lifecycle; choosing it initially at organization setup is an application default, not a rule
that every customer must use these phases.
| Setup | PDLC workflow | Intended use |
| --- | --- | --- |
| Recommended | Define → Design & Specify → Build → Verify → Release | Start with the five-stage BLOM lifecycle and configure the applicable gates and actors. |
| Minimum | Plan → Build → Check → Ship | Use the existing small-team profile to combine planning and specification, keep checks explicit, and record release and any follow-up with less ceremony. |
| Custom example | Define → Design & Specify → Build → Verify (Tests → Code review → Security review) → Release (Dev → UAT → Production) | Expand verification steps and environment paths to match the firm's needs; each environment retains its deployment, validation, and gate records. |
Minimum is a compact setup example, not a fixed minimum number of phases. Plan combines Define
and Design & Specify; Check covers Verify; Ship covers Release, and any follow-up, such as checking
results, is recorded there or in a follow-up Job. Applicable standards, gates, actor permissions,
and evidence requirements remain in force in every setup. The steps and environments in the
custom example are editable.
| Phase | Minimum useful outcome / gate basis |
| --- | --- |
| Define | Establish the problem, intended user/outcome, scope, owner, the item it belongs to and that item's existing documents, applicable profile, and governing standards. Assess incoming reports, such as Bugs and Issues, here or in a Triage step a firm adds; a report stays at intake, and the Job that takes it on carries any further work into later phases ([Task types](#task-types)). |
| Design & Specify | Define proportionate acceptance criteria and intended behavior at the useful product level; use Design Lab and optional micro apps where helpful, and record a selected visual and interaction design for handoff, in a D-Spec where one is needed. Write a T-Spec where the technical design needs agreement, and write or revise a DB-Spec when the work changes persistent data. Map applicable requirements to checks in a V-Plan, using inline planning when sufficient. Reference existing ADRs or record consequential new architectural decisions when required. |
| Build | Implement the authorized scope, including any migrations, against its governing revisions, testing and reviewing throughout the work; retain partial work and changed assumptions. |
| Verify | Evaluate the candidate against applicable criteria, tests, and reviews; resolve blocking findings before integration. This checkpoint gathers required evidence; testing also happens during Build and after deployment. |
| Release | Record permitted integration, deployment, environment validation, and exposure separately. Follow the configured environment path and its entry/exit gates, applying migrations before the code that depends on them; retain candidate identity and production health results. |
Establish standards during product setup and maintain them as needs change. Individual work
selects the applicable revisions and addresses relevant gaps; it does not recreate the standards.
Product setup also records who may grant approvals and exceptions before a process profile
exists; until it does, nothing counts as approved
(Approvals and exceptions).
Approvals are configured gates at the relevant transitions, including approval to build and
release where required. They may be shown as explicit review steps. The performer, evaluator,
and permitted moving actor are authorized separately; evaluation or transition permission does
not require holding the task assignment.
Firms can expand **Verify**, for example, into functional tests → code review → security review,
and **Release** into integration → Dev deployment/validation → UAT deployment/validation →
production deployment/validation. Each configured step identifies its purpose, applicable checks,
responsibilities, permitted transitions, and completion conditions. Added steps can appear within
a phase or as separate phases; removing a label never removes an applicable mandatory requirement.
These configure the process, not a task's actions: no task's actions are planned ahead, and a
[next action](#next-actions) is suggested by whoever finished the last one, or set when it is blank.
An environment-specific check still needs evidence from the actual target environment.
No four-level bundle of specifications is required: write at the useful level and reference the
governing product context. Design Lab can lead, accompany, or refine a specification, but building
still needs explicit scope and acceptance criteria. ADRs can apply at Product as well as
Capability, Feature, Component, or custom levels. Standards, design work, checks, and decisions
can be revisited when findings change the work.
### Customization and gates
BLOM has three layers:
| Layer | Purpose | What a customer can change |
| --- | --- | --- |
| BLOM core | The shared meanings in this document: core distinctions, core terms, and results. | Local terminology and presentation; the underlying distinctions remain intact. |
| Starter methods | Ready-to-use examples of a coherent process, such as the Recommended lifecycle. | Copy, rename, shorten, extend, or replace the workflow and its optional defaults. |
| Customer process profiles | A customer's actual phases, action types, roles, transitions, requirements, and completion rules for a scope of work. | Configure and version the process within applicable organization requirements and explicitly granted exceptions. |
A firm may bring its own process without mapping every phase one-to-one to the starter.
A named PDLC expresses the process profile. Each approved version identifies its configured
workflow and exact revisions of its definition standard and component guidance. A Job records
the version it follows. Publishing new guidance or changing the current PDLC does not replace
that record; adopting a different version is explicit and preserves earlier evaluations.
A PDLC definition is an S-Std in the PDLC category. Its inclusion in an adopted-standards view
does not replace the exact version pins governing existing work.
Configure who performs work, evaluates a gate, moves the work, and authorizes exceptions.
Approval comes from the configured check against a particular revision, purpose, and scope.
Sign-off can belong to an eligible person or an authorized identified agent, separately attributed
to that agent and its accountable person, or the check can be automated. An agent qualifies only
for the configured approval scope; human-only checks still require a person. Self-approval rules
must account for the author and their accountable person and related agents where required;
an Administrator label alone is not a universal method permission.
For every controlled move,
a gate result and the moving actor's permission are separate. Automatic advancement requires
an explicit setting and a permitted actor. Observe records an unmet requirement, Warn exposes
it before a permitted move, and Block prevents the move unless the requirement is satisfied or
excepted. Only a Mandatory requirement can be a blocking requirement; an Advisory one is observed
or warned ([Standards](#3-standards)). Locked company rules cannot be overridden locally, and a
profile edit grants no new authority. A company rule can also require a check at a phase move or
checkpoint, such as a security review record before Production for auth changes. It is a gate
requirement: no profile, the organization's or a team's, can remove a locked one, and suggesting
another next action never satisfies it.
Use Process and Gates for the detailed rules, next actions,
process publication, and additional profile examples. Each named environment can repeat entry
checks, deployment, validation, and exit checks; see
Delivery and Evidence.
Design Lab is part of BLOM for relevant front-end work, available
before or alongside specification and during delivery. Its reviewed revisions feed the D-Spec
and work brief.
## 3. Standards
Standards define reusable rules and expectations for the hierarchy items, documents, work, and
checks they apply to. A standard is an S-Std, one of BLOM's eight governing document types, with an
owner, a primary home, identifiable revisions, and for each rule its applicability and requirement
strength. It follows the same revision, approval, and history rules as every governing document
([Spec state](#spec-state)). Unlike the specs, ADRs, and plans in [Specs](#4-specs), a standard
doesn't belong to one item's [document set](#document-sets): it usually has its home at
Organization, Team, or Product, and governs whatever its applicability names, across many items.
| Topic | Rule |
| --- | --- |
| Applicability | Which items, document types, work, environments, or conditions a rule governs, decided before evaluation ([Results](#results)). It is content of the standard, like the rule itself: changing it is a new revision, which takes effect under the [policy timing rule](#when-a-new-standard-revision-applies). BLOM, the product, may record its reading of a rule's applicability, as it records placement; where the two differ, the standard's text wins. The decision for particular work applies the standard's stated applicability to the work's recorded facts and is recorded with its basis ([Results](#results)); the text-wins rule concerns the product's reading of the standard, not that decision. Placement alone doesn't decide it: a standard owned at Organization doesn't apply every rule to every descendant. A design-library interaction rule applies to a web interface and not to a data-only migration, while a security rule can govern both, and a shared component can be subject to rules from an affected product outside its own ancestor path. |
| Strength | How binding a requirement or rule is. **Mandatory:** it must be met or covered by a valid exception. **Advisory:** it should be met; it can be departed from with the reason recorded, and its unmet result stays visible. **Informational:** guidance shown with the rule; it is never evaluated to a result and never a gate requirement. Every requirement in a governed document carries a strength: a specification standard maps the words it uses, such as *must*, *should*, and *may*, to these three. Strength is content, like applicability, and is separate from the evaluated result and from the enforcement mode (observe, warn, or block), which Process and Gates owns. Only a Mandatory requirement can be a blocking requirement; an Advisory one's unmet result is observed or warned, never block-enforced. A category doesn't make every rule mandatory or every check applicable. |
| Departures | A local document can't silently waive an applicable rule. Departing from a Mandatory rule needs an exception from the rule's owner, where the rule permits one. An Advisory rule can be departed from with the reason recorded; the departure never satisfies the rule, and the rule and its unmet result stay visible. A document records its departures in its own text; work records them on the task, with the actor and time, and they are audit records ([Audit Layer](#7-audit-layer)). An authorized override of an open company rule changes which rule applies; a locked company rule can't be overridden (Process and Gates). |
| Verification | V-Plans plan the checks of applicable Mandatory and Advisory rules, and evidence records their results (Delivery and Evidence); informational guidance has no check. |
Where a non-functional requirement lives, in a standard or in an item's documents, is set out in
[Non-functional requirements](#non-functional-requirements).
### Recommended standard types
These are editable starter categories, not a required bundle of documents for every change. Define or
adopt standards when establishing the product, then reuse the applicable versions throughout
delivery. Update them when the work introduces a new need or changes an existing decision.
| Standard type | What it can govern |
| --- | --- |
| Brand | Voice, visual identity, terminology, content, and permitted brand usage. |
| Design library | Reusable design patterns, interaction states, design tokens, accessibility, approved component usage, and optional micro apps. |
| Engineering architecture | System boundaries, interfaces, data conventions, dependencies, and engineering constraints. Measured service targets belong to Operations. How it sits beside ADRs and T-Specs is in [Where architecture lives](#where-architecture-lives). |
| Data | Naming and modeling conventions, required fields, the data classification and access model, retention and deletion defaults, migration policy (for example additive-only in Production, or expand and contract), approval for destructive changes, and data review requirements. |
| Specification | Required content and acceptance criteria, supported product/capability/feature/component scope, versioning, review, and change handling. |
| PDLC | The process definition and component guidance pinned by a named PDLC version; configuration, guidance revisions, and approval remain distinct records. |
| ADR | When an architectural decision needs a record, required context/options/rationale, ownership, acceptance, and supersession. |
| Testing | Which checks apply by work type, risk, and environment; expected coverage, evidence, failure handling, and reruns. |
| Security | Applicable access and data-protection requirements, security reviews/checks, finding disposition, and exception authority. |
| Operations | Performance, availability, reliability, capacity, observability, backup and recovery targets, and incident response, each with how and in which environment it is measured. |
A specification standard governs how specifications are written and maintained; an ADR standard
governs decision records. Neither substitutes for the particular specification or ADR it governs.
Firms can add categories and tailor open rules while retaining locked company requirements.
Reusable defaults are starting text, not approval or an automatic update to a firm's rules.
Adopting a default still records the required approval of its exact revision; importing it or
including it at setup does not supply that decision. Reverting a standard creates a new draft
revision from the default and retains prior history. A PDLC revert similarly creates a new draft
version of its starter configuration and text. New defaults do not rewrite adopted material;
explicit acceptance and applicable approval are required.
The design library may include optional micro apps: reusable experiences assembled for a
focused user task. They remain library assets with source revisions and reuse guidance, not required
hierarchy levels. See the Design Lab guide.
### When a new standard revision applies
Each spec, plan, and ADR records the revisions of the standards it was written against. A new
standard revision applies to an existing document when that document is next revised. It never
rewrites existing documents or their approvals, and work keeps the revisions it was building
against.
Where a standard revision also changes what work must do, such as adding a check, review, or
gate requirement, that part is a policy change. It declares when it takes effect, by default at
each task's next phase gate, under the
policy timing rule.
PDLC-definition and component guidance pinned by a recorded PDLC version are the exception:
new revisions reach that work through adoption of a PDLC version pinning them, not the generic
next-gate default. Other newly effective company policies retain their
explicit timing and cannot be evaded by pinning an old profile. Here a *component standard* is a
standard a PDLC version lists in its approved set, not a Component item. Standards outside that
set, such as an organization's independently adopted Testing standard, follow policy timing.
If the standard's owner needs existing documents brought to the new revision sooner, that is
work: it is tracked through tasks, with the timing the revision declares.
## 4. Specs
This section defines BLOM's specs, ADRs, plans, and reviews. With S-Std, defined in
[Standards](#3-standards), they make up BLOM's nine document types: eight governing types that
retain intent, design, decisions, standards, and plans, and Review, which records assessment
evidence. Review appears in the same document-type catalog while keeping its own record rules.
### Document sets
Each item has a **document set**: the specs, ADRs, and plans that define or govern its scope. The item exists independently of those documents and can
exist before any of them. Its set holds the specs, ADRs, and plans whose primary home is the item,
and documents homed elsewhere that govern it: those its own documents cite as governing
references, and those whose recorded scope names the item, such as an R-Plan that includes it. A
document's recorded scope is the part of it that names the items it covers: an R-Plan's included
items, a V-Plan's scope, an ADR's decided scope. A P-Spec's prose *Scope* section isn't one, and
a D-Spec, T-Spec, or DB-Spec has none; they reach other items through governing references. Each
governing reference names its exact revision and the part that applies, such as a requirement,
data entity, or release scope. The set is derived from document homes and references: it is not
another document type, hierarchy level, or list to maintain. Organization and Team are ownership
and policy scopes and have no document set, and an initiative, which links governing documents,
has none of its own.
| Relationship | Example | Meaning |
| --- | --- | --- |
| Homed at the item | The Invite member P-Spec, homed at the Invite member Feature. | The item is the document's primary home. |
| Shared governing reference | An authentication ADR, homed at Product. | The decision governs this item and others; it isn't copied into each. |
| Shared design reference | An identity DB-Spec, homed at the component that owns the data. | The item uses the entities and rules it names; data ownership stays with that component. |
| Release participation | A Product R-Plan including Invite member and Accept invitation. | The item takes part in a release whose plan covers several items. |
A link kept only for context, such as a design alternative explored before selection, can be shown
beside the set; it doesn't govern the item.
Reviews of documents in a set can be shown beside it through their reviewed-subject links. A
Review is attached to a Job and supplies evidence; it is not a governing member of the set and
does not acquire an item home merely by reviewing that item's documents.
Each governing document in the set has one primary home, given by its recorded home (in this
repository, its Home line), whatever folder or store holds it. A document several items share is homed at the
component that owns it or, where none does, at a common ancestor such as the Product; a DB-Spec
follows the owning-scope rule in [Database design](#database-design-db-spec). A
document whose scope spans products is homed where its type permits, at one of them or at the
component that owns it, and reaches items in the other products through their documents'
governing references or, where its type has one, through its recorded scope, since Team and
Organization have no document set. An item can have several
documents of one type when their scopes justify it, such as several ADRs or successive R-Plans,
and one document can apply to many items. A reference changes no primary home, hierarchy parent,
or access permission.
Which documents a scope needs comes from the applicable process and standards, and is evaluated
like any other requirement ([Results](#results)). The Design & Specify phase of the
[Recommended lifecycle](#recommended-blom-lifecycle) names the usual triggers for design, data, decision,
and verification documents; an R-Plan follows the candidate being released
(Release plans). Creating an item, or
a task on it, doesn't require a new document of every type: a set can use existing documents
and permitted inline content. A required document that is missing is a gap, and is never
relabeled Not applicable to complete the set.
A set has no approval of its own. Each document keeps its own revisions, approvals, and evidence:
approving an item's P-Spec doesn't approve its T-Spec, an ADR, or a release, and a complete set
doesn't show that anything was built or verified. A set is read in a named context, such as the
item now, one task's scope, a verification candidate, or a release, because each can be
governed by different revisions: the item-now context reads each homed document's governing
revision and the references it makes, and the governing revision of each document whose recorded
scope names the item; a task's context reads its brief; a verification candidate's reads its
V-Plan; a release's reads its R-Plan. Adding or removing a governing reference changes governed
content
under the usual [revision rules](#revision-identity). A change to a shared document exposes the
items that use it for reassessment; it doesn't replace the revisions governing their active work.
Within a set, the types connect. A D-Spec, T-Spec, or DB-Spec answers named P-Spec requirements; a
T-Spec or DB-Spec cites the accepted ADRs it relies on; a V-Plan maps Mandatory and Advisory
requirements and applicable standard rules to checks; and an R-Plan names the candidate, document revisions, and V-Plans a
release relies on. These are relationships, not a writing order: design exploration can come
before a finished P-Spec, and an existing ADR can govern a new feature.
### Document types
| Short name | Full name | Definition and contents |
| --- | --- | --- |
| S-Std | Standard | Defines reusable rules with their applicability and strength; see [Standards](#3-standards) for its definition and revision rules. |
| P-Spec | Product Specification | Defines what the product or scoped part should do and the outcome it should support: intended behavior, scope, requirements, and acceptance criteria. It can describe Product, Capability, Feature, Component, or custom scope; its nesting follows the configured hierarchy. |
| D-Spec | Design Specification | Defines the selected visual and interaction design developed or refined in Design Lab: layouts, user flows, interface states, interactions, and applicable design requirements. It links the governing prototype revisions and identifies mocked behavior and unresolved design questions for handoff. |
| T-Spec | Technical Specification | Defines how the scoped solution is intended to be implemented: relevant interfaces, integration behavior, and engineering constraints. It connects the technical design to the governing product and design intent, references applicable architectural decisions, and references the DB-Spec for persistent data; a small data change can use an inline DB section instead. |
| DB-Spec | Database Design Specification | Defines the persistent data a scoped solution relies on and how existing data changes: entities and fields, keys and relationships, constraints, each entity's write-owning module or component, data classification and access rules, retention and deletion, expected access patterns and indexes, and the migration plan. It references the governing P-Spec, T-Spec, and data-related ADRs; its applied state is observed per environment. See [Database design](#database-design-db-spec). |
| ADR | Architecture Decision Record | Records a consequential architectural choice: context, alternatives, chosen approach, rationale, and consequences, with its scope and decision status. It explains why the choice was made and can reference the T-Spec that describes the selected implementation design. Accepting an ADR is an approval with the purpose Accept: it binds the ADR's revision and scope, is granted by passing the gate check configured for it, and follows the same rules for rejection, withdrawal, and supersession as any approval. |
| V-Plan | Verification Plan | Defines how applicable spec criteria and standards, including security, will be checked: governing revisions, tests or reviews, responsible actors, environment, pass criteria, and expected evidence. Actual results are recorded separately; see Verification plans. |
| R-Plan | Release Plan | Defines how an identified candidate and scope are intended to reach the required environments and audiences: promotion steps, responsible actors, gate and V-Plan references, rollout, rollback or recovery, and post-deployment checks. Actual deployments and exposure are separate records; see Release plans. |
| Review | Review | Records an assessment of exact subjects, including the reviewer, time, independence, verdict, findings, and attached Job. See [Reviews](#reviews). |
These are document purposes, separate from hierarchy levels. Specifications, standards, designs,
and decisions retain governing knowledge. [Tasks](#5-tasks) track the delivery and
investigation that references it. Jobs belong with tasks. V-Plan, R-Plan, and DB-Spec are the
accepted names for verification planning, release planning, and database design.
### Reviews
**Review is a document type for assessment evidence.** It is the existing review record, shown
in the common document catalog, not a second document copied from that record. A Review has an
identity, an attached Job, the exact subjects reviewed, the reviewer and review time, the kind
and round of review, the reviewer's independence, one verdict, and findings or an explicit
statement that there are none. Subjects can include a document revision, a commit, a pull
request at a recorded head, or a Job brief revision; a moving link alone does not identify what
was reviewed. Record the scope and basis for the assessment so its limits are visible.
Every Review is attached to a Job, including a sub-job when that is where the review work
belongs. It may assess several subjects without becoming several records. Each finding has an
identity, severity, and a recorded status: open, fixed by named later work on the Job, or moved
to a named Job or Bug. A Bug still reaches work only through a Job that takes it on. The Job's
timeline links the review and later work on its findings; a review is not a task or a next action.
Requesting or performing a review is work on the attached Job.
A Review is recorded whole, rather than moving through a Draft → Approved document lifecycle.
The recorded assessment is preserved. A later review round is a new linked Review; corrections
and finding dispositions add attributed, dated records without replacing the original verdict
or findings. A pending request is not a recorded Review. Its exact subjects and evidence remain
scoped to what was reviewed, and changed subjects require reassessment for a current claim.
A verdict, including one worded **Approved**, records the reviewer's conclusion; it grants no
authority. Where the configured gate uses a review, passing that gate produces a separate
approval bound to its revision, purpose, and scope. A favorable verdict or a finding marked
fixed does not by itself verify behavior, complete the Job, or authorize release. The
review-record procedure covers capture,
follow-up, and evidence use.
### Non-functional requirements
A non-functional requirement says how well, how safely, or under what conditions the product
behaves, rather than what it does: access control, data protection, performance, availability,
accessibility, retention, and the like. It is a kind of requirement, not a document type. Where
it lives depends on its scope:
| Scope of the requirement | Where it lives |
| --- | --- |
| A rule that applies across many specs or tasks, such as "every operation checks the caller's permission" | An S-Std of the matching category ([Standards](#3-standards)), often Security, Operations, Data, or Design library. As a company rule it can be locked. |
| A target for one product or scoped part, such as a response time or an availability level | A requirement with acceptance criteria in that scope's P-Spec, citing any standard it tightens. |
| How the design meets it | Visual and interaction responses, such as keyboard navigation and focus states, in the D-Spec where one exists, otherwise in the T-Spec or the work brief; technical constraints in the T-Spec, each traced to its standard rule or P-Spec requirement; data access, classification, and retention in the DB-Spec. |
| How it is checked | V-Plan checks, with evidence scoped to its revision, environment, and audience. |
A P-Spec can tighten a standard's rule for its scope but never silently loosen it: departing from a
Mandatory rule needs an exception from the rule's owner, where the rule permits one, and departing
from an Advisory rule records the reason and leaves the rule's unmet result visible
([Standards](#3-standards)). Like any
Mandatory or Advisory requirement, a non-functional requirement with no check covering it is a gap,
never a pass; informational guidance needs none ([Results](#results)). Many hold only in a given
environment, so evidence from one environment does not show the requirement is met in another.
### Where architecture lives
Architecture is not a document type or a hierarchy level. Each part of it lives in the document
that owns that kind of content:
| Part of the architecture | Where it lives | How it connects |
| --- | --- | --- |
| Rules the items must meet | An Engineering architecture [standard](#3-standards), homed at the Organization, a Team, or a Product. Several can apply to one item at once: the organization's, its team's, and its product's. | Each governs the items its applicability names. Rules from different levels that can be met together all apply, and a team's or product's standard can't override a locked company rule (Company rules). |
| A consequential choice, and why it was made | An ADR homed at the item it decides: the Product for a system-wide choice, a Capability or lower item for its part. | The T-Specs and DB-Specs that rely on it cite it. Within its decided scope, and wherever a document cites it as a governing reference, it governs other items directly, as a shared ADR does in [Document sets](#document-sets). A choice promoted to a reusable policy, applying beyond that scope by applicability, becomes a rule in a standard that cites the ADR. |
| An item's architecture: its structure, interfaces, and constraints | A T-Spec homed at that item, such as the Product's system architecture or a component's design. | It cites the ADRs it relies on and is written against the standards that apply to it. |
| Persistent data | A DB-Spec homed at the Product, the data-owning Capability, or owning Component ([Database design](#database-design-db-spec)). | It cites the data ADRs and the Data standard; items that use the data reach it through their documents' references. |
| Whether the architecture is followed | V-Plan checks and their evidence. | They check the applicable standard rules and the T-Spec's criteria. |
An item's [document set](#document-sets) shows its architecture: the T-Spec and ADRs homed at it,
the ADRs whose decided scope names it, and the ADRs and specs its documents cite. Which standard
rules apply to it follows each rule's applicability, not where the standard is homed
([Standards](#3-standards)). An Engineering architecture standard can define the product's layers
and the rules for each layer, and an item's T-Spec says which layers the item touches.
### Database design (DB-Spec)
Use a DB-Spec when work adds or changes persistent data structures, access rules, or retention,
or migrates or backfills existing data. Data outlives the features that create it, needs its own
reviewers, can change irreversibly, and must reach each environment before the code that depends
on it. A small additive change to data that isn't shared, sensitive, or already populated can use
an inline DB section in the T-Spec instead.
| Section | What to record |
| --- | --- |
| Scope and sources | The Product, data-owning Capability, or owning Component; governing P-Spec, T-Spec, and ADR revisions; the applicable Data standard revision. |
| Data model | Entities or tables; fields with types, nullability, and defaults; keys; relationships and cardinality; constraints and enumerations; stored versus derived values. |
| Ownership | The single module or component allowed to write each entity, and its permitted readers, under the product's architecture. |
| Classification and access | Sensitivity, such as personal, financial, or secret; who can read and write which rows; tenancy boundaries; encryption; audit or history needs. |
| Lifecycle | Retention, archival, deletion, and legal holds; soft or hard delete; append-only or versioned records. |
| Access patterns | Key queries, expected volumes and growth, indexes, and performance targets. |
| Change plan | Migration steps and their order relative to dependent code (expand → migrate → contract); the compatibility window; backfill and how it is validated; reversibility, or approval for an irreversible step; locking or downtime impact. |
| Consumers | APIs, events, summaries, and integrations that read or write the data, and their compatibility expectations. |
| Verification | The V-Plan checks that cover the design and its migrations. |
| Open questions | Unresolved modeling or migration choices. |
A DB-Spec's home is the Product, the configured Capability whose module owns the data, or the
owning Component. Document placement grants no write ownership:
each entity has one write-owning module or component, checked against the architecture. A
Product-level design can cover several owners while each entity still has one. Recognize the
Capability by its configured level identity, not its label; if the scheme has no Capability,
infer none. For placement, Component means the lowest configured level,
not any item that happens to have no children. Consumers link to the same design identity. An ADR records a consequential data architecture choice, such as a new
data store or the tenancy model; the DB-Spec records the concrete design that follows from it.
In [spec state](#spec-state), each environment shows the schema revision observed there, and a
difference from the approved DB-Spec is a gap. The
Delivery and Evidence guide covers data
checks, migration order, and recovery.
### Spec state
Spec state combines revision, approvals, checkout activity, environment observations, and linked
metadata for the eight governing document types, standards included. Review follows the
[review-record rules](#reviews), not this draft, approval, checkout, and environment lifecycle.
Show the governing document's facts together while keeping their
meanings distinct. Draft → Approved → Checked Out → Production is not a single required
lifecycle: a new draft can coexist with an older
approved revision that still governs production.
| State dimension | What to show |
| --- | --- |
| Draft and revision | Spec identity, revision, author, change reason/summary, and timestamps. Show the current draft and the relevant approved/governing revisions separately. Revising an approved spec creates a new draft revision and preserves the original. |
| Approved(s) | Each applicable approval's exact revision, purpose, scope, evaluator, basis, and time. Design, build, security, or release approvals are examples selected by the process; show pending, granted, rejected, withdrawn, expired, or not-required dispositions with their basis as applicable. |
| Checked Out | Who is actively using or revising a particular document revision, why, for which scope and linked task, and since when. Example reasons are Revising spec, Building, Investigating, or Verifying. Keep active, returned, handed-off, and cancelled checkout records and timestamps distinguishable. |
| Environments | A row or view for each environment in the effective process profile, such as Dev, UAT, or Production. Link intended spec/release targets and actual candidate observations separately, with governing spec revisions, verification, exposure/audience, source, and observation time. |
| Related metadata | Ownership and product hierarchy scope; parent/child and shared-reference links; exact governing document versions; tasks, PRs, commits, bugs, issues, feedback, revisions, and change history. Distinguish linked records and their observed states from proof of completion. |
#### Pending review and approval
A document never carries its own next action. A governing document's pending review or approval is a
[next action](#next-actions) on the Job that creates or changes it. The document shows the
pending step under its approvals and links to that Job, so the step appears in the
reviewer's or approver's queue like any other. A document that needs a review or approval with no
change underway, such as an existing document awaiting its first approval or a standard due for
periodic review, gets a task for that step. The task can be in its
[minimum form](#work-briefs-and-proportionality).
#### Revision identity
An approval, a governing reference, or a piece of evidence names an exact revision, so each
revision needs an identity that can't change afterwards. That identity is the document's ID and
revision number, plus a pointer to the revision's exact content: the stored revision when BLOM,
the product, holds the document, or, where documents are files under version control, the commit that last
changed the document's content.
A document's content is its governing text: requirements, criteria, scope, design, interfaces,
data rules, rationale, and a standard's rules with their applicability and strength. Its record
parts record facts about revisions: approval and
disposition rows, status and governing-revision lines, links to pending work, correction entries,
and revision history. Changing a record part adds a record and doesn't create a new revision, so
recording an approval never changes what was approved.
These revision rules apply to governing documents. A Review is recorded whole under
[Reviews](#reviews), without an editable draft or approval transition.
Before any approval, a draft can be edited within its revision. Once a revision has an approval,
any change to its content starts a new revision. The exception is a correction that changes no
requirement, criterion, scope, interface, or data rule: it is recorded as a correction entry,
leaves the approved revision unchanged, and, like every correction, adds a record rather than
rewriting one ([Audit Layer](#audit-rules)). A correction that changes meaning is a new revision.
#### Checkout activity and revision handling
A checkout records a named person's or registered agent's activity, not a Git checkout operation.
Record its governing/base revision, reason, scope, linked work, start and last-update times, and
the agent's accountable person where relevant. When a [next action](#next-actions) works on a
document revision, starting that use records the checkout; ending the actual use returns it.
Reassigning the Job or replacing a step never silently clears a checkout or resource still in use;
end or transfer that use explicitly, preserving the partial work. Show other
active checkouts and overlapping scopes so parallel building, investigation, or proposed revisions
remain visible. Whether a checkout is exclusive follows the
[overlap rules](#declared-scope-and-overlap-rules): by default, editing a draft revision is
exclusive, and building against an approved revision is not.
Building against a spec uses its governing revision without automatically creating a new draft.
Revising it preserves the approved base while developing a separate proposed revision. New intent
goes through applicable reassessment and approvals before adoption. Returning or cancelling a
checkout records the result and next action; a handoff records the next actor and supplied
revision. An idle checkout shows its last update; authorized recovery follows [Assignment and active work](#assignment-and-active-work).
#### Configured environments and linked records
Environment state describes implementation governed by the spec, rather than a document being
deployed. Use the environment names and ordering the effective profile configures;
Dev/UAT/Production are examples, not fixed slots. One spec can have different revisions
represented in different environments,
and an environment can have mixed candidates or audiences. Retain partial, missing, unknown,
failed, conflicting, or stale observations instead of assigning one global environment label.
For a DB-Spec, each environment shows the schema revision or migrations observed there. For
standards, decisions, or plans, show applicability and linked implementation/release context
where relevant rather than inventing a running document revision.
A PR link includes its source identity, relevant branch/commits, linked work and spec revision,
and last-observed state; a merged PR establishes integration to its observed target only. Bugs,
issues, and feedback retain their identity, disposition, affected revisions, and links. Revision
history records who changed what and why, with prior approvals and evidence still attributable
to their original scope.
Missing or inaccessible links stay visible. These are relevant metadata fields, not a required
form to fill in completely before a draft can be saved.
For example, one P-Spec can show all of the following at once:
| View | Example observation or activity |
| --- | --- |
| Draft | Revision 3 proposes revised export behavior; its required build approval is pending. |
| Checked Out | A product owner is revising revision 3; an engineer is building against approved revision 2 in separate linked work. |
| Approvals | Revision 2 is approved for its build scope; revision 1 retains its applicable production approval. |
| Dev / UAT | Dev has observed candidate A tied to revision 2 with partial verification; UAT targets revision 2 but has no confirmed deployment yet. |
| Production | Candidate B is observed for the recorded audience under revision 1, with its own evidence and observation time. |
Summaries use the hierarchy path while retaining these separate facts. See
Authority and independent status dimensions
and Environments, release, and product truth.
### Parent and child P-Specs
P-Spec nesting must match the configured product hierarchy. Each P-Spec
has one primary home at its Product or a lower item. Its structural nesting and reporting path
come from that item's actual ancestors, including custom levels; there is no independently
editable spec tree. A Feature P-Spec under the onboarding Capability belongs in that branch,
not beneath an unrelated capability merely because a spec link was added.
Each remains the same document type with its own identity, scope, owner, revisions, and criteria;
"sub-spec" describes the relationship, not a separate spec type. Specs remain optional at each
level. If a Capability has no P-Spec, retain the Capability node between Product and its Feature
P-Specs in navigation and summaries. Do not create a placeholder spec or drop the hierarchy level.
A feature spec can therefore exist before any ancestor spec while retaining its full product path.
| Example product scope | P-Spec purpose | Example nesting |
| --- | --- | --- |
| Product: Member portal | Overall purpose, users, outcomes, and product-wide requirements. | Parent of the onboarding capability P-Spec when both exist. |
| Capability: Member onboarding | The complete onboarding outcome and coordinating behaviors. | Parent of Invite member and Accept invitation feature P-Specs. |
| Feature: Invite member | Detailed invitation behavior, flows, and acceptance criteria. | Child of the onboarding P-Spec; can have a delivery component P-Spec. |
| Component: Invitation delivery | Functional responsibilities and expected interface behavior. | Child of the Invite member P-Spec in this example; implementation design can reference a T-Spec. |
A P-Spec has at most one primary parent P-Spec link, and that link must follow the ancestor path
of its home item. A governing spec link cannot reorder structural nesting. Intervening nodes
stay visible even when they have no spec. Reject cycles and parent links to sibling or unrelated
branches. Shared components or requirements retain
one identity with usage/reference links from other specs; those links do not create structural
parents or duplicate their contribution to primary totals.
Hierarchy changes or explicit changes to a spec's primary home preview and update the structural
path together. Preserve prior placement and governing versions; identify affected parent links,
requirements, work, and V-Plans for reassessment. A move changes current organization and reporting,
not approval or the intent governing existing work. Changed intent still requires explicit adoption.
Children reference the applicable parent requirements and their exact governing revisions,
then add their own detail and criteria. Avoid copying parent text into each child. Requirements
from other affected scopes still apply. A child cannot silently override an applicable constraint;
resolve a conflict through an authorized governing revision or scoped exception.
Parent revisions or changes to nesting/product scope expose affected children, work, and V-Plans
for reassessment. Preserve prior governing versions and record adoption of changed intent;
editing a parent does not silently replace the intent governing active work. Mandatory policies
still apply under the existing process rules. Parent approval does not automatically approve a
child. Completing or verifying the children does not establish the parent's full outcome: its
V-Plan can reference relevant child checks and add integration or complete-journey checks.
## 5. Tasks
Tasks are tracked bodies of work: Jobs, which people or agents act on, and reports, the Bugs,
Issues, Feedback, and Change requests that people or agents record and assess. Jobs are how the
product changes ([How work changes items](#how-work-changes-items)), and a report reaches that
work only when a Job takes it on ([Task types](#task-types)). Each task has an identity, primary
product home, ownership, and recorded progress or disposition. Delivery work moves through the
configured PDLC by way of its [next actions](#next-actions), and references the specifications,
standards, designs, decisions, and plans governing it. An incoming report can be captured while
its intended scope or required action is still unknown.
### Task types
| Task type | Purpose | Example |
| --- | --- | --- |
| Job | Deliver a defined piece of work, planned or taken on from a report; it can have sub-jobs, which are also Jobs. | Deliver CSV export, with sub-jobs for its API and interface, or build just the API described by an existing P-Spec. |
| Bug | Record and assess a confirmed mismatch with governing intended behavior; a Job that takes it on makes the correction. | An export fails the existing CSV acceptance criteria, and a Job takes the Bug on to fix it. |
| Issue | Record and assess a reported problem, concern, or question whose cause or disposition may be unknown. | Assess a report that export results look incomplete. |
| Feedback | Record and assess an observation, experience, or suggestion before deciding whether change is needed. | A customer says the export options are hard to find. |
| Change request | Record and assess a proposed change to intended behavior or scope; a Job that takes it on revises the spec and delivers the change. | Propose PDF export; the Job that takes it on revises the affected spec through its applicable gates. |
The organization owns one configurable task-type catalog. Each entry has a Job or report base
kind, which a renamed or firm-added label does not change. Customers may name an Incident,
Spike, or other type, but must say whether it carries work as a Job or assesses a report;
process profiles govern its workflow, not a separate definition of its kind. Assess is available
to reports for their own assessment and to Jobs for investigation or measurement. Employee
Ideas can use Feedback with an Employee report source instead of becoming a third underlying kind. An issue can
be classified as a bug after investigation while retaining its identity, report, and evidence;
reassess any affected process requirements. A change request proposes a change to evaluate; the
Job that takes it on produces the resulting spec revision, a version of the governing document.
Feedback can lead to investigation, a confirmed bug, a proposed change, a Job that takes it on,
or a deferred/dismissed disposition with the reason recorded. Preserve its source, original
content, and links when reclassifying it or creating related work. Capturing feedback does not
commit the team to implement it.
**Reports reach work through Jobs.** Bugs, Issues, Feedback, and Change requests are reports.
Only a Job does work in items: a report records what was reported and the
items, documents, standards, or process it concerns without changing them, and does its own assessment. Anything more, such as a
spec, code, verification, or release, is done by a Job that takes the report on, even for a
one-line fix, and a report never becomes a Job by changing its type. The Job that takes it on is a new one, or an open Job whose scope covers the work,
and it links the report; the report keeps its identity, source, evidence, and its own disposition.
A report stays in an intake phase, such as Define or a Triage step a firm adds, and never moves
into Build or later; the Job that takes it on does.
Several reports may be taken on by one Job, and one report may lead to several Jobs. A report
can close at intake for its own assessment before or after a linked Job finishes. Its disposition
and the Job's completion are separate: neither assessment closure nor a takes-on link claims a
fix, delivery, resolution, or approval. Record which work each Job takes on and what it delivered.
If a linked Job closes without delivering, retain that outcome. An open report with unresolved
work and no remaining relevant open Job shows **No job yet** again; another active takes-on Job
is not hidden. Flag a closed report for its owner, without reopening it automatically. Archive
uses the same rule; closed-without-delivery links remain history, not evidence of resolution.
### How work reaches a Job
Suggestions enter as reports; already-defined work may enter directly as a Job. Reports,
Review findings, gaps, plans, specs, Design Lab outcomes, standard changes, and other Jobs can
prompt work. A permitted actor decides whether to open a Job or extend a suitable open Job's
brief, recording the source, scope, and authority. None of these inputs creates or starts a Job
by itself. A takes-on link is not Job parentage; a new item appears only when its Job first needs
it. Feedback and ideas can be deferred or declined with reasons instead of creating delivery work.
### Task state
The question "where is this work?" has several separate answers. Keep them distinct:
| Answer | Meaning | Entered or derived |
| --- | --- | --- |
| Phase | The PDLC phase the work is in, such as Build. | Moves through permitted transitions; a parent retains its own recorded phase for its steps and gates, alongside the summary under [Jobs and sub-jobs](#jobs-and-sub-jobs). |
| Next action | The typed step the work is waiting on, and who does it, or blank. | Suggested by whoever completed the previous action, or opened the task; a permitted actor can change or set it. |
| Active work | Who is actually performing which step or step contribution. | Attributed execution records, independent of assignment. |
| Activity | Current work condition; see below. | Uses actual execution, blockers, and recorded pauses or deferral. Assignment alone never means Active. A blank next action normally shows Backlog unless Paused. |
| Gate | Whether the checks for the next phase move are met. | Evaluated from evidence and approvals. |
| Disposition | Why a closed task closed. | Entered at closure. |
| Assignment | The task's one current assignee, including a report's. | Recorded and retained across steps until reassigned or unassigned. |
| Checkout | Who is actively using a particular document revision. | Linked to actual execution and its declared scope; resource overlap rules determine exclusivity. |
For example: **Phase: Build · Next action: Code (API lead) · Activity: Blocked, waiting for the
export API**. Activity labels describe work within the configured process; they do not add a
second required PDLC or replace its gates. Offer these editable starter states:
| Activity state | Meaning |
| --- | --- |
| Backlog | Captured or deferred work awaiting assessment, selection, or scheduling, or open work whose next action is blank; record unresolved scope, and the next action once one is known. |
| Ready | The next action can start and its conditions are met; assignment alone does not start it. This is not approval for any later step. |
| Active | A non-idle execution is doing the next action or a step contribution; idle work is shown separately. |
| Blocked | The next action is prevented, for example by an unmet dependency; show the blocker and responsible actor. |
| Paused | Work is intentionally suspended; record the reason and condition or owner for resuming. A paused task can have a blank next action and stays Paused. |
| Closed | The task has a recorded disposition, such as Completed, Duplicate, Declined, or Cancelled. |
Completed relates to the task's declared purpose and completion criteria. Duplicate links the
canonical task; Declined records a decision not to pursue it; Cancelled ends previously
planned or active work. Closing a creating Job as Duplicate offers to add its item to the
canonical Job's targets through that Job's authorized brief change; it neither moves the target
silently nor retires the item. Blocked, Paused, and deferred work are not completed outcomes. Preserve
who changed state, when, why, and any remaining obligations. Reopening retains the earlier closure
and follows the correction routes;
post-release findings are normally taken on by a new linked Job. The configured observe/warn/block
rules and actor permissions still determine each supported move. Closing a task ends its live
executions; record the end or transfer of resource use explicitly and preserve partial work.
### Next actions
An open task's **next action** is the typed step it is waiting on: what must happen, who may do
it, its exact subject, and what counts as done. It may be a small group of parallel steps.
Actions live on tasks, never on items or documents. A document needing review or approval has a
Job for that work. A report's actions stop at assessment; a Job takes on any ensuing change.
**Suggest one step at a time.** Opening a task or completing its current step may suggest the
next catalog action, permitted phase move, or closure. Future actions are not a fixed plan.
A blank next action means no required step is set; it is not a closure request. An explicit
"no further step; close" requests closure, which still checks permissions, criteria, gates,
and sub-job closure. A suggestion grants no authority and satisfies no requirement.
**Assignment and performance.** Jobs and reports keep one assignee across steps. Ordinary catalog
work, including report assessment, requires its eligible assignee. Reviewers and approvers
instead record their own eligible steps without taking assignment; this is an explicit exception
to the earlier assignee-only completion rule. A phase move or closure requires
transition or closure permission, not assignment. Step contributors retain their own attributed
outcomes. The assignee records a parallel group's completion only when all required outcomes and
join conditions are met, without impersonating contributors or supplying their approval.
**Results and transitions.** A completed attempt records its exact subject, performer, outcome,
evidence, optional note, time, and next suggestion or explicit closure request. Failed and
Changes requested are completed attempts, not successful checks. Apply a required return before
any automatic forward move; validate the suggestion against the resulting phase and actor.
One completion leaves at most one next action. Automatic moves obey current permissions,
revision checks, gates, owed returns, and phase-limited actions; they never complete or replace
an action. The Process and Gates procedure
owns evaluation order, replacement, and override handling.
People and identified agents take and suggest actions. CI and other automations supply evidence
or execute configured automatic transitions; they do not become next-action performers. A person
or agent who initiates a deployment remains its performer, with the automated run as evidence.
**Editable starter catalog.** The organization owns action types and teams may extend them. Each
type names eligible performers, completion conditions, outcomes, and who may replace it. Any type
may run in any phase unless the profile restricts it. A parent's own step uses its step phase,
not the displayed phase summary of its children.
The full starter action catalog records
eligible performers, **Done when**, and **Outcomes** for Assess, writing and design, ADR, approval,
Code, reviews, verification, Migrate, and Release. These are editable starters, not a required
path. Authorized agent approval is a distinct optional type; its label grants no permission.
Replacing an unfinished action records actor, reason, authority, and **Overridden**, not Done.
It ends that execution; actual resource use or checkouts must separately end or transfer, with
partial work preserved. A required check remains required even if its suggested action is
replaced. Assignment persists unless explicitly changed.
**Queues** show required steps separately from assignment notices and note mentions. A blank
action creates no step obligation, although the actor can still see the Job or a mention.
The [work list](#capturing-and-finding-work) retains every task and its current state.
Codex records and assesses the Bug **CSV export drops the last row**, then opens a Job to fix it.
The Job proceeds through Code by Codex, Claude's Review requesting changes, corrected Code, a new
Review, permitted Production approval, and Release. Reviewers and approvers record their own
steps while Codex remains assignee. Each Review pins its subject; a failed verdict finishes the
attempt but does not satisfy the gate. Closure checks the Job's criteria and sub-jobs. The Bug
stays at intake, retains its link, and records its own assessment disposition. An employee idea
uses Feedback with source Employee report and reaches a Job only when defined work is selected.
### Capturing and finding work
**A todo is a task.** BLOM has no separate todo list, note, or register for work. Anything
that needs doing is a task: a Job, Bug, Issue, Feedback, or Change request. Work that isn't
ready to start waits in Backlog, and its minimum form can be as short as an outcome, with a next
action once one is known. Each person's, role's, or agent's queue is their todo list.
**Work found along the way.** When a session finds work outside the task it is on, such as
an unrelated bug or a needed follow-up, it captures that work as a new task in Backlog and
links it from its session close. It doesn't fold the work into its current execution or leave it as
a note. Remaining work on the current task stays with its next action.
**The work list.** A work list shows every task on one line with its key fields: ID, type,
title, home, owner, activity, priority, and next action, with who it waits on and since when.
People and agents use it, with their queues, to find work without opening every task. It is a
view derived from the tasks, never a second record. Where it is kept by hand, every change
to a task updates its line, and if the two disagree, the task wins and the line is
corrected.
### Priority, severity, and planning
**Priority** records the team's chosen order of work. **Severity** records the assessed impact
of a bug or issue, including affected users and scope. Use separately configurable values;
severity can be unknown during assessment or not applicable to other work. A serious problem
and its scheduling decision remain distinguishable. Record the rationale and changes where
relevant. An optional rank orders work within a priority band; rank is not urgency or permission.
Urgency, target dates, and effort estimates are optional planning fields; estimates
are not promises. An AI may propose classifications within its assigned role. Lowering risk, or
reclassifying work so that requirements drop, needs exception authority; see
Process and Gates.
### Report source and origin
Classify where a Bug, Issue, Feedback, or related request originated independently of its work
type. Offer editable source categories such as **Client/customer feedback, Employee report,
Partner/vendor report, Automated check/monitoring, AI-agent finding, and Other/Unknown**.
These describe discovery or reporting, not who caused a defect or how severe it is.
Retain the original reporter or reporting system when known, the person/tool that entered the
record, the channel (such as support, email, in-app feedback, a test, or monitoring), original
report/reference, and report time. Record the observed environment, candidate/release, and
supporting evidence where known. For example, a support employee entering a client's complaint
records **source: Client/customer feedback; reporter: client; entered by: support employee**.
An employee's own observation is an Employee report. A production environment is observation
context, not a substitute for the source category.
Allow unknown fields at intake and refine them with history. Several client, employee, or system
reports may link to one canonical task; retain each report's origin when deduplicating or
reclassifying work. Distinguish report counts from unique-work counts. Source classification
doesn't confirm a bug or set priority, and missing or inaccessible source material stays
explicit. Existing access rules apply to reporter details and references.
### How work changes items
A task's brief names, in its scope, its **target items**: each item the work acts on, and
what it does to it. Only a Job has target items; a report records the items it concerns without
acting on them ([Task types](#task-types)).
| Effect | Meaning |
| --- | --- |
| Create | Adds a new item under a named parent, such as a new Feature under its Capability. |
| Change | Changes an existing item's intent (in new revisions of its documents), its implementation, or both. A fix against unchanged intent changes only the implementation. |
| Retire | Takes the item's behavior or part out of the product. Retiring records intent; removing the behavior from each environment is recorded like any delivery. The item stays in the hierarchy as retired, with its identity, documents, evidence, and history. New work targets a retired item for only two purposes: to finish or correct its retirement, such as removing remaining code or data or fixing a failed removal, with the effect retire, which leaves it retired; or to restore it, with the effect change, which returns it to active. |
A target item covers that item only: work that also changes a child or a shared component names
it too. Until the target items are known, the brief says so; unknown is never recorded as none.
Target items can be added or dropped as the work is understood, and each such change is a new
brief revision that reassesses the affected authority and evidence
([Work briefs](#work-briefs-and-proportionality)). An execution's declared scope stays within the
Job's target items
([Declared scope](#declared-scope-and-overlap-rules)).
Work that changes no item, such as an investigation, the assessment of a report, a declined
change, verification, approval, or standards/process work, records that
it has no target items; it keeps a primary home like any task, and it ends with its
findings, results, or disposition. A task with target items is homed at its target item or, when
several are in one product, at their nearest common ancestor. When they span products, it is
homed at one of them, chosen and recorded with the reason, and the other products' requirements
still apply. A release has no create, change, or retire effect of its own: its release
record names the delivered items and versions and links the Jobs carrying those effects.
Work on an Organization or Team standard is homed at a chosen Product with the reason recorded;
this does not move the standard's own home. Until a new item exists, its named parent stands in for it, except that a new
product is added when the work creating it opens. A home that changes with the target items is a
recorded move.
A new item is added to the hierarchy when the work creating it first needs it, as the home of a
document, in an execution's declared scope, or for a change, not when the idea is captured, and it records the
work that created it. If that work is cancelled or declined, it retires the item only when no other Job has changed
it, no other open Job targets it, and retirement authority, approval, and the conditions below
are met. A completed Job's changes still count: cancellation of a creating
parent cannot retire an item already changed by a completed sub-job. Otherwise preserve the
item and record the disposition and any separately required retirement work. Reopening that work is a new brief revision under
the usual authority and history rules: if it resumes creating the item, it restores it, a change
that returns it to active; if it reopens only to finish or correct the item's retirement, it
targets the item with the effect retire, and the item stays retired. An item is retired only
after other open work on it is closed or retargeted, each child is retired or moved, and each document homed at it that
governs an active item is rehomed. An item with no documents, work, or evidence, such as one
added by mistake, can be removed by a structure edit; any other item is retired, never deleted,
except as the retention rule allows ([Audit rules](#audit-rules)).
Structure editing, such as recording a Product container, mapping what already exists, moving
an item, or renaming one, organizes the hierarchy without changing product intent or
implementation. The product's current Add a product route is such a recorded edit; a later
Job-based creation route does not make this route untracked. It is recorded as its own change
under the
reorganization procedure,
and a process can require work for it.
These links give every item a history: the work or structure edit that created it, and each task
that changed or retired it, with the revisions and evidence each relied on. A change to an
item's intent or implementation under no task that targets it is a gap, like any unlinked
change ([Audit rules](#audit-rules)).
### How tasks relate to specs
A Job may create or clarify a spec, implement governing intent, correct implementation
against an unchanged spec, or investigate whether any change is needed; a report investigates
only through its own assessment ([Task types](#task-types)). A task does not always
require a new spec or a spec revision. Link applicable document revisions as they become known;
keep unknowns visible during assessment, then establish bounded scope, completion criteria,
governing references, and applicable approval before implementation. Its governing references
select the part of its item's [document set](#document-sets) the work relies on, so several
tasks on one item can use different parts. A task can also cite a document outside its
item's set, such as a standard, or an ADR whose decided scope doesn't name the item and that none
of the item's documents cites; the citation adds nothing to the set.
Completing an assessment can mean recording a disposition or linking work, such as a new or open
Job that takes the report on. Multiple Jobs can implement one P-Spec, and one task can reference
several governing documents.
### Work purpose and completion
State the intended result in the work brief and label relevant links as creates, revises,
implements, verifies, or releases where applicable. These labels describe the work's links to
documents and releases; its effect on items is named by its
[target items](#how-work-changes-items).
Research, Design Lab exploration, testing, documentation, and maintenance can all be Jobs; firms
may add specialized work types.
| Purpose | Typical PDLC entry | Completion basis |
| --- | --- | --- |
| Investigate | Define or the current phase's assessment step | Record findings or measured results, evidence limits, disposition, and any linked follow-up; a finding does not imply a fix. |
| Create or revise a spec/design | Design & Specify | Deliver the identifiable revision and obtain the approvals required for its stated purpose; a draft-only exploration can have a different declared result. |
| Build or correct implementation | Build once applicable scope and authority are established | Deliver the scoped change and the checks/handoff required by its profile; production release is required only when included in this task's completion scope. |
| Verify | Verify or a configured testing/review step | Record the required results against the relevant candidate, criteria, environment, and audience, including failures or gaps and their disposition. |
| Release | Release at the applicable environment step | Record the authorized release actions and required validation/exposure for the named environment and audience. |
A task's next actions follow from its declared purpose, as each actor who finishes one suggests
the next, rather than forcing every task through every phase.
Configured closure rules retain failures, valid exceptions, overrides, and unmet checks.
A Job can span specification through delivery and divide that scope among sub-jobs. A planning
Job whose promised result is a set of defined, independently linked Jobs can complete when
those briefs and links meet its criteria; it does not claim that their work is delivered.
If it makes them its sub-jobs, it remains open until they have all closed. A delivery Job
still owes its own delivery criteria, even if every sub-job has closed
([Jobs and sub-jobs](#jobs-and-sub-jobs)).
For corrective work, which a Job does while any report that prompted it stays at intake
([Task types](#task-types)), investigate unknown causes first. A mismatch against clear unchanged
intent returns to Build; changed or ambiguous intent returns to Design & Specify; a changed
underlying outcome returns to Define. Apply each return's own conditions and retain prior
evidence. The correction procedure
defines active-work rework and post-release follow-up without requiring a new spec for every fix.
### Work records, assignments, and grouping
A Job is a task, not an assignment or document. It has one current assignee, who may work directly
from its brief. Divide separately tracked work into sub-jobs or other linked Jobs; record
step contributors' execution scopes without creating multiple current Job assignees.
The accountable work owner, current assignee, permitted performers, and approvers are distinct
roles even when one actor fills several. An identified agent retains its accountable person.
Handoffs retain the current brief, exact document revisions supplied, progress, evidence,
blockers, and remaining work. Ending a session does not unassign the Job. See
actor responsibilities
and continuity.
One P-Spec may govern several Jobs; each retains its own scope and completion criteria.
[Ownership and outcomes](#ownership-and-outcomes) owns initiative membership and historical links.
The term *task* names records previously labeled Work items and, before that, Body of work.
### Task notes and timeline
A brief task note, on a Job or report, records its author, time, and content. Corrections append an attributed entry;
they do not silently rewrite history. The timeline links notes, assignment changes, steps,
Reviews, and finding dispositions to their source records.
A mention brings a note to an actor's attention. It does not assign a task, create a required
step, approve a change, or mark work done. Capture resulting assessment in the report, or delivery
in a Job, under [How work reaches a Job](#how-work-reaches-a-job). Character limits and notification presentation belong in product specifications;
Process and Gates owns handling.
### Jobs and sub-jobs
Sub-jobs are a foundational part of BLOM's work model.
Any Job can have explicitly linked **sub-jobs** when parts of its work need their own scope,
ownership, next actions, or completion tracking. A sub-job is an ordinary Job with a parent
relationship, not a separate task type or a product hierarchy level. A Job need not have a
parent or any sub-jobs. Permitted depth is configured. BLOM, the product, allows **three Job
levels in its MVP: Job → sub-job → sub-sub-job**, with more later through an organization setting.
The same relationship rules apply at every permitted level.
- **One parent, no cycles.** A sub-job names exactly one parent Job. A Job cannot be its own
parent or become an ancestor of itself. Adding, changing, or ending a parent link is an explicit
recorded change, preserving who changed it, when, why, and the earlier relationship. Adding or
changing a parent must keep the entire affected subtree within the allowed depth.
- **Explicit decomposition.** Creating a Job from another Job records its origin; it becomes a
sub-job only when that parent relationship is recorded. A Bug, Issue, Feedback, or Change
request is still a report; its takes-on Job is linked to the report, not its sub-job.
- **Each remains a Job.** Parent and sub-job each retain their identity, brief, product home,
accountable owner, target items, assignee, steps, phase, governing references, process,
next action, evidence, and completion criteria. Membership follows [Ownership and outcomes](#ownership-and-outcomes).
A parent's target items or scope do not silently become its sub-job's. Each records the work
it actually carries.
- **Parentage grants nothing.** It supplies no approval or access and grants a parent's owner
no authority over a sub-job's assignment or execution. Each Job follows its own applicable permissions, rules,
and gates. Linking a sub-job does not start it or plan its future next actions.
- **Dependencies are explicit.** A parent link creates no waits-on dependency and does not
order sibling Jobs. When one Job needs another's result, record a dependency with the required
result and checkpoint under [Dependencies](#dependencies-for-starting-work-and-reaching-environments).
The all-children-closed rule below is a separate condition of parent closure.
- **Parent progress follows its work.** A parent's phase is the least advanced phase among its
open sub-jobs and its own current step, using the configured phase order. Its own steps are
kept to a final check; its sub-jobs carry the decomposed work. A summary phase grants no
approval and does not replace any Job's applicable gate checks or invent a next action.
This is its displayed summary. The parent separately retains its own recorded phase for steps
and gates; child progress does not move or authorize that phase. Show both where they differ.
A child that is itself a parent contributes its summarized phase. If the phases are unknown
or cannot be compared under the configured order, show that gap rather than an invented phase.
With no open child or current step supplying a phase, use the parent's own recorded phase.
If that is also unknown, show unknown, never inferred completion.
- **Children close before their parent.** A parent can close only when all its sub-jobs have
closed. An open sub-job keeps the parent open and visible with that unfinished work and its
owner; closing the parent never closes children on its behalf. All children being closed is
necessary, not sufficient: the parent records its own disposition against its own criteria
and final check. A cancelled or declined child is not evidence that its work was delivered.
Closing a sub-job does not complete its siblings or initiative. Removing a parent link does
not satisfy unfinished completion criteria. A closed parent cannot gain an open child.
Before reopening a child under a closed parent, reopen the parent under its own rules or end
the link with the change recorded on both. Reconcile any closed ancestors before leaving an
open child beneath them.
For example, the **MVP initiative** groups **Deliver CSV export** and its sub-jobs **Build the
export API**, **Build the export interface**, and **Verify the complete export journey**. Each
sub-job has its own brief and owner; verification depends on the required API and interface
results. Deliver CSV export stays open until those sub-jobs close, then completes its final
check against its own delivery criteria. The initiative may also contain unrelated Jobs and evaluates its own completion
criteria. [Ownership and outcomes](#ownership-and-outcomes) owns initiative membership; the
Delivery and Evidence guide owns closure detail.
### Archiving and reopening Jobs
Archive preserves history while removing a Job from operational lists and counts. A parent
archive includes its descendants. **Check the whole subtree first**: permissions,
closure conditions, retirement safeguards, live work, and linked-report consequences. If any Job
cannot close, change nothing and name it. Recheck before applying the whole operation so a changed
permission or child cannot leave a partly cancelled tree. Then record Cancelled with reasons for
still-open Jobs, deepest first, preserving existing dispositions, and archive the closed subtree.
Closing ends live executions; resource use ends or transfers explicitly. Preserve partial work,
evidence, links, and outstanding obligations. Ordinary parent closure never cancels its children.
Archived history stays accessible. Unarchive restores visibility, not an open disposition.
Reopening separately reconciles home, initiative, and parent links under [Jobs and sub-jobs](#jobs-and-sub-jobs),
retaining earlier closure. See the closure procedure.
### Dependencies for starting work and reaching environments
Attach each dependency to the point where its result is needed. The starter checkpoints are
**Start work, Dev, and Production**. Dev and Production refer to the environments the effective
profile configures; a profile may rename, omit, or add environments such as QA, UAT, or Preview.
A checkpoint names the specific action it constrains, so integration, deployment, validation, and exposure are not
treated as interchangeable.
| Dependency checkpoint | Required result example | When it is evaluated |
| --- | --- | --- |
| Start work | The required API contract revision is available and approved for implementation. | Before starting the named implementation activity; assessment or unrelated permitted work can still proceed. |
| Dev | The compatible export API candidate is deployed and validated in Dev for the consuming feature's checks. | Before the named Dev deployment or validation step; a rule about merging to the dev branch is instead labeled as integration. |
| Production | The compatible API and required migration are available and validated for the production audience. | Before the specified production deployment or exposure step. |
Each dependency records the supplying task, item or released item version, artifact, or external prerequisite; required result
and relevant revision/compatibility; consuming activity or target environment/audience; accountable
owner; gate/evaluation rule; and evidence with source and time. Show each dependency's
[result](#results), with next action where needed. A linked task's
Closed label or merged PR is insufficient when the condition requires a running, validated
candidate. Reassess affected dependencies when the candidate, governing revision, environment,
audience, or prerequisite changes. A mutable In work number cannot identify the dependency;
name the stable item and required result, or an exact released version.
An unmet Production dependency need not block starting work or Dev when their own conditions
are satisfied. Evaluate it at its named checkpoint under the existing observe/warn/block rules;
use block where the dependency must prevent the move, with exceptions only where permitted.
An unmet dependency can also hold back a next action, which shows the work as Blocked. Manual
records and checks can support this model; the phase gates of BLOM, the product, don't control external merges or
deployments. See
requirements and enforcement and
environment paths.
Keep dependency links separate from assignments, a Job's initiative, parent/sub-job links,
product parentage, and the link between a report and the Job that takes it on. Use step
contributions to divide work within one task, or sub-jobs when those parts need independent Job
records. Other related or dependent Jobs need no parent link. Sub-jobs are supported without
requiring every Job to have a parent; the Job that takes on a Bug is linked to the report, not
placed beneath it.
### Work briefs and proportionality
Keep the work brief as fields on the task:
desired outcome, accountable owner, current assignee and performers, scope and non-goals, including a Job's
[target items](#how-work-changes-items) or the items a report concerns, applicable authority,
completion criteria, evidence expectations, and unresolved assumptions. Link its process profile,
product and owning-scope context, any items it relies on without changing them, exact governing
document revisions, and environment/audience where relevant. The brief is versioned work data; it
is not a J-Spec or other new specification type.
The minimum form can be short. A documentation correction may need an outcome, bounded edit,
review/check expectation, and handoff. A release-sensitive change can require a separate spec,
specialist approvals, several evidence types, and an explicit release decision.
Changing material scope produces a new work brief revision and reassesses the affected authority
and evidence. An editorial correction should not invalidate unrelated decisions. Preserve why
a revision changed and which ongoing executions need to adopt it.
**Sizing work for one session.** Size an execution so one accountable session can carry its
step or step contribution to a useful result and handoff. A Job can span sessions, and a
parent can span sub-jobs. A session may coordinate subagents on declared, non-overlapping scopes,
retaining their attribution and covering their work in its session close. Split work that cannot
fit into sub-jobs, other linked Jobs, or step contributions. Product specs follow product
scope; they are not split merely to fit a session. Assignment persists across these sessions.
Blocked and paused work retain their reason and next action; cancelled or abandoned work retains
its closure resolution and unfinished obligations. Urgent changes can use an authorized expedited
profile or exception; record any deferred obligation, responsible owner, and follow-up.
### Task setup examples
| Setup | Example and useful fields |
| --- | --- |
| Minimum | A help-page correction names product, outcome, owner, assignee, actual performers, bounded edit, criteria, references, phase/activity, and review or handoff. No separate spec or dependency is needed unless required. An unassessed report can start with less. |
| Default | A client Bug and its takes-on Job retain separate owners, assignees, performers, criteria, and outcomes. Use [report provenance](#report-source-and-origin), [brief fields](#work-briefs-and-proportionality), and named dependency checkpoints; the link does not resolve the Bug. |
| Custom example | Two teams' API and interface Jobs share an initiative and use configured Start, QA, UAT, and Live checkpoints, specialist checks, and resource coordination. Shared work retains one identity and primary owner; labels and eligible actors follow the profile. |
These examples scale the existing work record rather than creating three new mandatory profiles.
Reuse inherited context, standards, and gates; show only relevant fields and unresolved required
information.
## 6. Work Coordination Layer
The Work Coordination Layer is how team members, AI agents, and teams work on the same product
without colliding. Before anyone starts, it answers three questions: is someone already doing
this, does my work overlap with someone else's, and who settles it if it does? Organizations and
teams configure its rules in their process profiles, and a company rule can set or lock them for
every product.
### Assignment and active work
A task, whether Job or report, has at most one current assignee: a person or identified agent.
A permitted actor may assign, reassign, or unassign it, recording actor, previous/new assignee,
time, reason where relevant, and notices. Assignment persists across steps and sessions; it is
responsibility, not a lock, lease, permission, or proof of activity. The [next-action rules](#next-actions) define who needs it to perform each kind of step.
An execution records task, step, actor, accountable person for an agent, scope, workspace, times,
results, and handoff. It ends on finish, handoff, or an attributed end. After the profile's idle
period without an update it shows **Idle**, not Active; idleness neither ends assignment nor
automatically transfers resources or authority. Other live executions can still make the task Active.
If an actor is absent or stuck, the task's work owner, resource owner, or an actor the profile
names can end or transfer the affected execution and resource use within their authorized scope.
Record who, why, retained partial work, resource disposition, and notice to the earlier actor.
Ending a record does not prove an external process stopped: explicitly stop, isolate, or transfer
its actual resource use before conflicting work proceeds. The earlier actor must recheck current
assignment, step, resource access, and permission before resuming. Session close records continuity;
it never silently clears responsibility or obligations. Profiles may limit concurrent active
executions; assignment has no lease or count-based automatic expiry.
### Declared scope and overlap rules
An execution declares what the actor expects to change: items, such as features or components,
document revisions, DB-Spec entities, code areas (repository and paths), and environments. The
actor can refine the scope as the work proceeds. An execution on a Job declares only items among its
[target items](#how-work-changes-items), and one that needs another item adds it to the Job's
target items first; an execution of a report's assessment declares nothing to change
([Task types](#task-types)). BLOM, the product, compares the scopes of active executions, and when
two overlap, the overlap rule for that kind of resource decides what happens:
| Overlap rule | Effect |
| --- | --- |
| Allow | Both executions proceed, and the overlap is visible. |
| Warn | Both actors see the overlap before continuing, and their acknowledgments are recorded. |
| Coordinate | Before starting, the second actor agrees a split or an order with the first actor or the owner, and the agreement is recorded. |
| Exclusive | The second use of that resource waits until the first ends or transfers. |
Overlap rules control resources and execution scopes, not assignment of the whole Job. They
apply to step contributors as well as separate actions. Starter defaults, configurable by
organizations and teams:
| Resource | Default rule | Why |
| --- | --- | --- |
| The same document draft revision, for editing | Exclusive | Concurrent edits overwrite each other; parallel proposals use separate draft revisions. |
| The same governing revision, for building | Allow | Many actors can build against one approved revision. |
| The same component or code area | Warn | Parallel changes are common but risk merge conflicts and regressions. |
| The same DB-Spec entity or migration | Coordinate | Schema changes must be ordered; two migrations on one table can block or corrupt each other. |
| The same environment, for deployment | Exclusive | One release at a time per environment. |
| A product or component outside the owning scope of the work's home product | Coordinate | Its owning team, or the accountable owner of a product the organization owns directly, must know and agree, and its requirements still apply. |
### Workspaces and integration
Each independently integrated execution that changes code or documents uses an isolated workspace.
For code, it has its own branch; unrelated concurrent executions do not share one. Changes reach a shared line, such as `dev`,
one at a time: a change that merges after another rechecks what the earlier change affected,
because its evidence may now be stale. The product enforces this for its own actions and records the
order of merges it observes in other tools.
### Teams working together
When work touches a product or component outside the [owning scope](#ownership-and-outcomes) of
the work's home product, that product's owner sees the declared work and, under the Coordinate rule,
agrees before the work starts. The owner is the owning team or, for a product the organization
owns directly, its accountable owner. Products in one owning scope, such as two the organization
owns directly, aren't outside each other's scope, so this default doesn't apply between them. The
contribution stays linked to the owner's product without creating a second owner. The
coordination view shows each team or accountable owner which of their products and components
others are changing.
### When collisions happen anyway
If changes collide despite these rules, for example through conflicting edits, a failed merge, or
overlapping migrations, record a coordination conflict naming the actors and affected scope. It is not automatically
a method gap: link a separate gap only where the conflict also leaves a required condition unmet. Resolve it explicitly by merging, redoing one change, or discarding one, never by silently
overwriting either. Reassess the evidence for whatever changed.
### Coordination example
| Event | Result |
| --- | --- |
| Codex is assigned the CSV-export Job and starts Code on `codex/csv-fix`. | Persistent assignment and current execution are recorded separately. |
| An authorized actor reassigns the Job to Claude. | Both actors receive the recorded change; Codex's partial work and any live resource use remain visible for explicit handoff. |
| Another Job changes the Export component on a separate branch. | Warn makes the code overlap visible; both actors acknowledge it before continuing. |
| Billing starts a migration on `export_job`. | Coordinate requires agreement on scope or order with the data owner. |
| A session stops responding. | After the configured idle period it shows Idle. An authorized recovery actor ends or transfers its execution and resource use, recording the handoff and notifying the earlier actor. Assignment does not expire. |
| Two releases need the same environment. | Exclusive serializes that environment use without locking either entire Job. |
## 7. Audit Layer
The Audit Layer lets people see who changed what, why, how, and under what authority, for the
records they can access. It traces a change back to its reason and forward to where it shipped.
It adds no new kind of work. Instead, it requires that the records BLOM already keeps can answer
the audit questions, link to each other, and are never rewritten. Those records are revisions,
next actions, assignments and executions, approvals, evidence, observations, decisions, and gaps.
### The audit questions
| Audit question | BLOM answer |
| --- | --- |
| What changed? | The versioned artifact and its diff: a spec, standard, plan, or work brief revision; a process, rule, or permission change; or a commit or pull request observed in GitHub. |
| Who or what changed it? | The actor: a person, an AI agent with its accountable person and session, a service account, or an integration. Who performed it, who entered it, and on whose behalf are recorded separately. |
| Why did it change? | The task and brief revision behind it (a job, issue, bug, change request, or feedback), the next action it completed, or the decision that required it. |
| How was it done? | The action or transition, the channel (directly in BLOM, the product; an agent's connection to the product; or an integration), and the process profile version. For an agent, also the context it was given. |
| What authority allowed it? | The approval (an eligible person's sign-off, explicitly authorized agent approval, or automated gate check), the rule or policy version, the actor's role and permissions at that moment, the agent's delegation, and any exception, departure, rule override, or next-action override. |
| What did it affect? | The items it targeted, and the specs, standards, code, data, environments, and releases it touched, through their links. |
| What evidence supports it? | Tests, CI checks, reviews, validations, and runtime observations, each with its subject revision, source, and time. |
| Where did it ship? | Integration, deployment, and exposure records: environment, flag, tenant, and audience. |
| What remains unresolved? | Open gaps, active exceptions, departures, and overrides, unmet requirements, unresolved active work or handoffs, unresolved coordination conflicts, and open risks. |
### What every audit record carries
Every change or action records:
- the record it changed, with the revision before and after;
- the actor, and anyone they acted for or any delegation they acted under;
- when it happened, and when it was recorded if that differs;
- the reason: a task, next action, or decision;
- the authority;
- the channel.
A field that can't be established, such as the reason for a commit observed in GitHub, is
recorded as unknown, never guessed. A field that doesn't apply is marked not applicable, with the
basis.
The records that already capture these facts are the audit trail itself. That includes revision
history, action completions, approvals, evidence, and observations; the Audit Layer links them
rather than keeping a separate account.
### Decision records
An ordinary product or process decision can be a short entry in an existing log. Record the
decider, date, choice, rationale, scope, source words or other basis, decisions superseded, and
links to the work or documents applying it. Distinguish the owner's words from an agent's
interpretation or applying choice. Preserve earlier decisions and append supersession or
correction; a new summary must not erase how the decision changed.
A decision record is not another governing spec type or an automatic approval lifecycle. An
architecturally significant decision belongs in an ADR; an approval must separately satisfy
its exact revision, purpose, scope, evaluator eligibility, and applicable rule. A Review informs
a decision but cannot silently supply its authority. See Review records.
### Audit rules
- **Append-only.** Audit records are never edited, and are deleted only under the retention rule
below. A new record that voids or supersedes the old one, with a reason, corrects a mistake,
and both stay visible.
- **Honest attribution.** Nobody records an action as someone else.
- An agent acts under its own identity, with its accountable person, delegation, and session.
- An automation or integration acts under its service identity.
- Work entered on someone else's behalf records both who performed it and who entered it.
- **Process changes too.** Changes to process profiles, action catalogs, overlap rules, company
rules, permissions, and agent delegations record the same who, why, how, and authority.
- **Unlinked changes are gaps.** A change observed in another tool with no linked task or
authority appears as an audit gap with an owner, and so does a change to an item's intent or
implementation under no task that targets it; a recorded structure edit isn't one.
Examples are a commit merged without a task, a change to a component's code under a task
that doesn't target that component, or a new version observed in an environment with no
deployment record.
- **Retention and lawful deletion** follow organization policy. Deletion or redaction is itself
recorded: it removes content without hiding that the record existed.
- **Access.** People see the audit trail only for records they can access; the trail never widens
access.
### Audit views
- **Record history:** every change to an item, spec, task, rule, or environment, newest
first.
- **Actor history:** everything one person or agent did, with the context each agent action was
given.
- **Trace:** traces a change in either direction:
- backward from a production observation, through the release, merge, evidence, and approvals,
to the task and its original reason;
- forward from a decision to everything it affected.
- **Export:** an audit trail for a scope and time range, for a compliance or incident review.
### Audit example
Tracing the fix that shipped in PR #42:
| Question | Answer |
| --- | --- |
| What changed? | `src/export/csv.ts` in PR #42, merged as commit `a1b2c3d`. |
| Who or what changed it? | Codex, an AI agent with the product owner as its accountable person, in session 7, assigned to the Job and performing Code within its recorded scope. |
| Why? | The Job "Fix CSV export's last row", which took on the Bug "CSV export drops the last row": brief revision 2, next action Code. |
| How? | The actions Code → Claude review → Human approval → Release, each suggested by whoever finished the one before, with CI's checks as evidence, under profile "Small team" v3, through Codex's connection to the product and through GitHub. Codex's context pack included P-Spec "Data export" revision 2. |
| What authority allowed it? | The configured gate's recorded evaluation of the required Review and CI check, the product owner's exact-candidate approval for Production, and Codex's scoped authority for the Export component. Claude's Review is evidence, not that approval. |
| What did it affect? | The Export component. It implements P-Spec "Data export" revision 2, with no data or schema change. |
| What evidence supports it? | CI run 1881 on the PR's final head commit, Claude's review record, and the new empty-export test. |
| Where did it ship? | Deployed to Dev, then to Production at 15:10, and exposed to all users with no flag. |
| What remains unresolved? | Nothing: the Job has no open gaps, exceptions, departures, or overrides. |
## Appendix: Getting started
These are example sequences for starting with BLOM, not a required order. A firm's process
profile decides what is required and when, and each step's documents and approvals follow the
sections above. Most steps are work, tracked as tasks like any other
([Capturing and finding work](#capturing-and-finding-work)): the Job that writes a new
capability's first P-Spec, for example, first creates the capability's item, while a capability
that already exists keeps its identity ([How work changes items](#how-work-changes-items)).
Mapping what already exists is structure editing, for which a process can also require work. A
step's output can be small, or left for
later where the process allows.
### Start with one Product and one Job
Record one Product and a bounded Job in its initiative. Name the outcome, target item or explicit
no-change scope, owner, assignee, current next action, applicable process and references, and what
will count as complete. Perform that step, link its evidence and exact reviewed subject, and
record any separate required approval. Then suggest the next step or explicitly request closure.
Add sub-jobs when scopes need separate tracking; add documents when intent or governance needs
them. The examples below show how that same foundation grows.
### A small team
For a few people and one product, Team is optional. Record the product's approval and exception
authorities, choose a starter profile, and adopt the standards it needs. BLOM's reusable defaults
cover Specification, ADR, Testing, and Security; copying them is not approval. Write or adopt
Brand, Design library, Engineering architecture, Data, and Operations rules when needed rather
than assuming every category ships with a template.
Define the Product and key capabilities in P-Specs, creating a new item when its Job first needs
it. Record consequential architecture in ADRs, data ownership in DB-Specs, technical agreement in
T-Specs, and planned checks in V-Plans. For a front end, establish Brand and Design library rules,
explore in Design Lab, and carry the reviewed direction into a D-Spec. Apply each required approval.
Create bounded Jobs and sub-jobs with target items, criteria, and current next actions; membership
uses [Ownership and outcomes](#ownership-and-outcomes). Approve Build at its gate, assign work,
and verify and release through the profile. These are examples, not required documents for every Job.
### A large organization
Map existing products, items, documents, and work before planning changes; record owning scopes,
accountable owners, baselines where needed, and approval/exception authority. Set shared company
rules, locked where necessary, then let teams tailor profiles within those rules. The organization's
profile covers products it owns directly; each team's profile covers its products. Earlier work
keeps its recorded versions until explicit adoption.
Follow the same specification and Design Lab path as the small-team example, reusing shared
standards. Shared documents follow their owning scope or common ancestor; DB-Specs follow
[data ownership](#database-design-db-spec). Plan initiatives such as MVP and Post-MVP under the
[membership rules](#ownership-and-outcomes), with dependencies across products. Record each Job's
owner, assignee, target items, and coordination needs. Build approved scopes in parallel using
isolated workspaces, explicit resource coordination, and R-Plans; the [Audit Layer](#7-audit-layer)
traces each result to its work, authority, and evidence.