BLOM — Boundary Layer Operating Model

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, 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). 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). 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

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:

The core distinctions, core terms, and 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.
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.
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). Tasks close, and the items they changed remain, with the record of each change (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).

Core terms

Hierarchy levels are defined in Hierarchy, standards in Standards, and the other document types in Specs.

Results

Every Mandatory or Advisory requirement is evaluated in three layers; an informational one is shown, never evaluated (Standards). Gates, dependencies, and summaries read the requirement result.

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.

Hierarchy definitions

An item's document set 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). Organization and Team own people and policy; their standards govern items by applicability, which placement alone doesn't decide (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), 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). 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), 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.

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.

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 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:

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). 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). Unlike the specs, ADRs, and plans in Specs, a standard doesn't belong to one item's document set: it usually has its home at Organization, Team, or Product, and governs whatever its applicability names, across many items.

Where a non-functional requirement lives, in a standard or in an item's documents, is set out in 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.

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, 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.

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. 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). The Design & Specify phase of the Recommended 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. 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

These are document purposes, separate from hierarchy levels. Specifications, standards, designs, and decisions retain governing knowledge. 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:

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). 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). 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:

An item's document set 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). 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.

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, 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, 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.

Pending review and approval

A document never carries its own next action. A governing document's pending review or approval is a next action 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.

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, 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). 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 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: 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.

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:

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.

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), and a report reaches that work only when a Job takes it on (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, 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

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:

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:

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 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).

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). An execution's declared scope stays within the Job's target items (Declared scope).

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).

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).

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). 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 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. Research, Design Lab exploration, testing, documentation, and maintenance can all be Jobs; firms may add specialized work types.

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).

For corrective work, which a Job does while any report that prompted it stays at intake (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 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. 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. 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. 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 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, 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.

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, 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 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

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 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, 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). 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 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:

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 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

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

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:

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): 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). 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. 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. Plan initiatives such as MVP and Post-MVP under the membership rules, 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 traces each result to its work, authority, and evidence.