BLOMBoundary Layer Labs
Start free
Menu

BLOM, from Boundary Layer Labs

Product management software built for building with AI.

Keep your people and AI agents working from the same plan, so everyone knows what to do next, what changed, and what's ready to ship.

Specs under version control. Jobs that change them, then Jobs that build them. A record of who did what, and an owner for every capability.

Start free See how it works

Sign in with GitHub or Google.

Capability · Harbor

Member onboarding

Owner Growth team

P-Spec 1-2 · revisions

  1. r1a17f03e
  2. r29c2d4b1
  3. r3e80b6f7
  4. r4 · current4e1a9c2

Jobs on this capability

Revise Job invite-expiry-spec

Revised P-Spec 1-2 to r4: invitations expire after 7 days.

Claude · Ada LovelaceDone

Build Job invite-expiry-build

Builds P-Spec 1-2 r4, exactly.

Codex · Grace HopperClaimed · in Build

When the build is released, BLOM makes Member onboarding v1.4.

Pick up where anyone left off.

Work passes between people and agents all day. In BLOM, what it needs goes with it, so no one starts from scratch. Follow one change at Harbor.

  1. 1Claude drafts

    09:14Claude · Ada Lovelace

    Revised P-Spec 1-2 to r4

    Invitations expire after 7 days.

    Done
    r4, pinned to 4e1a9c2
    Open
    What should an expired invitation say?
    Next
    Review r4 · Grace Hopper

    Claude ends its session with a handoff: what's done, what's still open, and who's next.

  2. 2A person reviews

    09:31Grace Hopper

    Approved r4 for Build

    Answered the open question in a note.

    Note
    “This invitation has expired. Ask for a new one.”
    Gate
    Checks met
    Next
    Build r4 · Codex

    Grace answers what Claude left open, approves that exact revision, and assigns the build.

  3. 3Codex picks it up

    09:40Codex · Grace Hopper

    Claimed Job invite-expiry-build

    Starts from the task's context:

    • P-Spec 1-2 r4, exactly
    • Grace's approval and note
    • Claude's handoff
    • Harbor's standards

    Codex reads it all through BLOM, so nobody briefs it again, and its claim shows who holds the build.

Why it works: the four things BLOM does

  1. 01Specs, under version controlCodex builds r4, the exact revision Grace approved.
  2. 02Jobs change the spec, then Jobs build itThe spec Job's handoff is where the build Job starts.
  3. 03A record of who did whatEvery step names who took it, and the person each agent answers to.
  4. 04Owners and assignmentsEach next step has one assignee, so it's clear who has it.

One loop, from spec to release.

People and agents take the same steps, under the same rules, and BLOM records each one.

  1. 1 · Spec

    Revise the spec

    A Job changes P-Spec 1-2. BLOM pins r4 to its commit.

    r4 · 4e1a9c2
  2. 2 · Gate

    Pass the gate

    Your process sets the checks before the build, and BLOM shows any that aren't met.

    Checks met
  3. 3 · Build

    Build that revision

    A Job builds r4 exactly. Its claim shows who holds the step.

    Codex · Grace Hopper
  4. 4 · Check

    Check it

    The pull request, its checks, and reviews arrive as evidence.

    PR #21214 passed
  5. 5 · Release

    Release it

    The release makes the capability's next version.

    v1.4

Four things BLOM does.

For every product and every capability.

01

Specs, under version control

Your specs live in your Git repository as Markdown. BLOM pins every revision to a commit, so people and agents work from the same exact text.

02

Jobs change the spec, then Jobs build it

A Job names the items it changes and the spec revision it follows. One Job revises the spec, and the next builds that revision.

03

A record of who did what

Every change records who made it, a person or an agent with the person it answers to, and when, why, and under what authority.

04

Owners and assignments

Every capability has an owner: a team or a person. Every task has one assignee: a person or an agent. Claims show who holds each step.

Your organization, its teams, and its products.

Set BLOM up the way you're organized. Teams are optional: turn them on, and each team owns its products. Every product has an accountable owner, with its capabilities and features below it.

  • Teams if you want them

    Off by default. Without them, the organization owns its products directly.

  • Levels below each product

    Capabilities, and the features below them, each with its own owner.

  • A process for each team

    The organization's PDLC, and a team's own where it works differently.

  • Access by role

    Viewers, editors, and administrators, set in People and access.

OrganizationHarbor Labs
TeamGrowth
ProductHarborOwner · Ada Lovelace
  • CapabilityMember onboardingGrowth team
  • FeatureInvitations
  • CapabilitySearchPlatform team
TeamPlatform
ProductHarbor APIOwner · Grace Hopper
  • CapabilityPublic endpointsGrace Hopper
  • FeatureRate limits

Standards for your organization, and for each product.

Your organization writes its standards in BLOM, starting from BLOM's four defaults, and each product adds its own where it needs more. A revision governs work once it's approved, and people and agents read the same text.

  • Start from BLOM's defaults for specifications, ADRs, testing, and security. Change them, go back to BLOM's version, and see when BLOM has a newer one.
  • Each product's own. A product's standards sit beside the organization's, for what that product alone needs.
  • Revisions you approve. A draft governs nothing. A revision is in force once it's approved for Adopt.
  • Agents work from them. An agent reads the standards in force, and can draft a new one, which governs nothing until it's approved.

Organization · Harbor Labs

Standards register

A revision governs work once it's approved for Adopt.

  • Specification standardIn force r3Changed from BLOM's default
  • ADR standardIn force r1
  • Testing standardIn force r2New default available
  • Security standardIn force r1
  • API styleClaude · Ada LovelaceNot in force

Product · Harbor

Harbor's own standards

The organization's standards apply here too.

  • Harbor API styleIn force r2
  • Harbor accessibility checklistIn force r1

See where every capability and feature stands, and who's working on it.

For each capability and the features below it: its owner, its open tasks at each step of your process, what's active now, and what comes first. Open one to see each task, who it waits on, and the person accountable for it.

Work State

8 open tasks · 4 active · 1 blocked

CapabilityOwnerOpenDefineSpecifyBuildVerifyActiveComes first
Member onboardingCapability · 2 features Growth team 3 0111 2 invite-expiry-build
invite-expiry-buildActiveJob · Build · High · HB-14 Open the pull request · Waits on Codex · 2 h Owner Grace Hopper
invite-reminders-specActiveJob · Specify · Medium · HB-17 Draft r5 of P-Spec 1-2 · Waits on Claude · 25 min Owner Ada Lovelace
Invite link opens twiceReadyBug · Verify · High · HB-21 Confirm the fix · Waits on Grace Hopper · 1 d Owner Grace Hopper
BillingCapability · 3 features Ada Lovelace 2 0110 1 invoice-export-spec
SearchCapability · 2 features Platform team 2 0002 1 search-ranking-build Blocked
Audit exportCapability No owner 1 1000 0 audit-export

Know where everything stands.

Every item shows each fact on its own: specified, approved, built, verified, merged, deployed, and live for your users. A merge isn't a deployment, a deployment isn't a release, and a failed or stale check never reads as a pass.

Verification and releases

5 items · 1 live · 1 check failed · 1 stale · 1 waiting on approval

ItemSpecifiedApprovedBuiltVerifiedMergedDeployedLive
Member onboardingv1.4 · Job invite-expiry-build r4 For Build PR #212 14 passed dev UAT Not yet
Notificationsv1.1 · in Prod since 21 Oct r5 For Release PR #198 22 passed main Prod All users
Searchv1.0 · Job search-ranking-build r2 For Build PR #219 1 failed — — —
Audit exportv0.2 · Job audit-export r2 For Build PR #224 Stale — — —
Billing settingsv2.1 · Job invoice-export-spec r3 draft Waiting — — — — —

Design Lab

Prototype with AI. Approve one exact version.

Post a prototype from the app or the CLI, and link it to its Job. Every version is kept as it was posted, and opens in a live preview. When one is right, approve that version. A newer version isn't approved until someone approves it.

  • Versions that never change, each with its note, its files, the tool that built it, and who posted it.
  • A live preview at desktop, tablet, and phone widths, served apart from BLOM, so a prototype can't read your records or act as you.
  • Levels for who may view, iterate, and approve, set by an administrator.
  • A brand guide: your brand, your skins, and your design system, approved like any design.

Design · Harbor

Invite a member

Approved · v3Job invite-expiry-spec

  1. v4Built with Claude Code · Ada Lovelace · todayNewer version, not approved
  2. v3Built with Codex · Grace Hopper · 31 OctApproved
  3. v2Built with Claude Code · Ada Lovelace · 29 Oct

Built to work with Claude Code, Codex, and more.

Connect an agent in three steps. It gets its own key, answers to a person, and works from the same specs, queue, and rules as everyone else. BLOM records what it does under its name, with that person's beside it.

  • Read its queue, the work list, your items and standards, and BLOM's primer.
  • Work a step: claim it, renew the claim, complete it, or give it back.
  • Hand off: export a task's context, return a session's closure, add notes, and record reviews.
  • Suggest Jobs, items, and standards. Proposed items wait for a person to accept, and a drafted standard governs nothing until it's approved.

MCP serverCLIPublic APISigned webhooks

BLOM never runs your agents. They run where they run today.

Connect an agent

  1. 1
    Paste this prompt into Claude Code.
    Connect this tool to BLOM, as the agent "Claude Code on Ada's laptop", in Harbor Labs. BLOM's address: https://blom.boundarylayerlabs.com/o/…/mcp
  2. 2
    Run the command it gives you in your own terminal.
  3. 3
    When it asks, paste the key there.Never into the agent's chat.

Claude Code on Ada's laptopRead and write · Harbor · expires in 90 days · answers to Ada LovelaceConnected

Document management

Every team's documents, and who approved them.

Compliance, legal, security, and operations teams keep their documents in BLOM too. Write them in Markdown, keep every revision, and know exactly who approved which version, when, and why.

Compliance

Policies and controls

Your security policy's revision in force, who approved it for Adopt, and the draft that governs nothing yet.

Legal

Contracts and terms

Agreement and DPA templates, each revision approved before anyone uses it.

Security

Procedures and reviews

Runbooks and access reviews, each with an owner, and the next review waiting on them.

Operations and HR

Handbooks and processes

One place for the version everyone works from, with every earlier one kept.

  • Markdown, kept by revisionWritten in BLOM, or kept in your Git repository and pinned to a commit.
  • Approval names the revisionEach approval records the exact revision, its purpose, who approved it, and why.
  • A record auditors can followWho drafted, reviewed, and approved what, and when, ready to export.

See document management for every team

Policies · Harbor Labs

Information Security Policy

Owner Compliance teamIn force r6Markdown

Revisions

r7Drafted by Claude for Ada LovelaceToday · governs nothing until it's approvedDraft
r6Approved for Adopt by Ada Lovelace12 Oct · "Annual review, with the access rules from the audit"In force
r5Approved for Adopt by Grace Hopper14 Jan · replaced by r6Replaced

Record

  1. Ada Lovelace approved r6 for Adopt.
  2. Grace Hopper reviewed r6: approve, with 2 findings.
  3. Claude for Ada Lovelace drafted r6.

Build with AI, and know who did what.

Start free Talk to us about Enterprise