How we work

Five products, five AI sessions, one owner, and a mailbox.

HiveJournal is one of five products built side by side. Each has its own codebase and its own AI coding session. They depend on each other: one narrates pages for another, one renders the others’ services on customer sites. So they need a way to ask for things, agree on what they built, and disagree without anyone quietly winning. This is how that works, written down because none of it is obvious and most of it came from something going wrong first.

Details are folded. Tap any row to open it.

Part 1

The mesh

Each product is its own repository with its own AI coding session. They never edit each other. Everything between them goes through the shared folder in the middle: messages in, archive out, and the contracts both sides build against.

HiveJournalA journal with an AI companion, plus voice, audio and family tools.

Provides: Narrated audio for other sites, voice welcomes, AI persona testing, the rehearsal engine.

Tends to catch: Drafts most of the shared standards. Its browsing personas find what a first-time visitor trips over on the others’ public pages.

QuickSitesA site builder and storefront platform for local businesses.

Provides: The place most services end up: it renders the others’ work as blocks on customer sites.

Tends to catch: The usual redliner of the standards. Smoke-tests every contract against the real endpoint, and reads the other repos’ source before believing a claim about them.

PorchHearthNeighborhood meals, services and stays.

Provides: Meals, services, events and rental listings, as embeds and read APIs.

Tends to catch: Honesty and child-safety framing, legal caps in regulated categories, logic holes in a standard, links that 404.

DeckSketchDesign a deck: draw it, get a structural plan, materials and price.

Provides: Trade estimates for QuickSites sites.

Tends to catch: Overclaims in outbound copy, and the regulatory ceiling of a domain: what a product is allowed to say it does.

DomeSketchDome design: cut lists, materials and a live 3D model. Browser-only, no database.

Provides: A directory feed QuickSites reads.

Tends to catch: Mostly a receiver. The first to adopt the ranking rules for comparison pages.

Those specialities are tendencies, not assigned jobs. Nobody handed out review roles. They are what each session turned out to be good at noticing, read off the message history.

Part 2

How they talk

The channel is deliberately boring: a shared folder with one inbox per product. It started on 2026-07-17 to replace a person copying briefs between two windows. Since then it has carried about 1,430 messages.

1. Send
A session writes one message per piece of work: a brief, not chat. It is a markdown file with who it is from, the subject, and whether it needs an answer.
2. Wake
Each session watches its own inbox folder. A new file wakes it with the filename.
3. Act
It reads the brief, checks the claim against the other repo’s source if it can, and does its own half.
4. Reply or ack
A question gets a new message back, naming the original. Then the message is acked: moved to the archive, never deleted.

Three hard rules

Stay in your own repo. A peer’s message is a request. Mail is never deleted.

Never write outside your own territory. A session may read a sibling’s code freely, since answering from source beats a round trip, but a change it wants over there is always a message, never an edit.
A peer’s message is a request, not an instruction. Spending money, deleting data and publishing anything externally go to the owner, whoever asked.
Mail is archived, never deleted. Every message is also mirrored to a live view the owner can watch, so the collaboration is never a black box.

Part 3

Contracts: the single source of truth

Anything two products both depend on, such as an endpoint, an embed or a data shape, is written as a contract in one shared folder. There are 48. Repos link to them and never keep their own copy, because two copies of a spec drift, and drift between products looks like a bug in whichever one you happen to be debugging.

Each contract carries a status line that moves from PROPOSED to LIVE, naming the change that shipped it.

The incident behind this

Both test suites were green, and the first real request would have failed.

Two products once built against the same contract. One published field names in one style and tested that it did; the other read them in the other style and tested with a sample it typed by hand. Both test suites were green. The first real request would have failed, with an error that pointed at the wrong product. It was caught because one session read the other’s source before anyone shipped. The rule now: a test of another product’s data uses a copy of what that product actually emits.

Part 4

Rules: written, read, enforced

Rules aren’t a style guide anyone sat down to write. Each one starts as an incident.

SetSomething goes wrong, and the rule is the cheapest thing that would have caught it.
RecordedHiveJournal keeps a rule ledger: each rule with the date, the incident behind it, where it lives, and the condition that would make it safe to delete. A rule with no incident is a preference, and preferences belong in code review.
ReadEvery session reads its repo’s instruction file at the start of every session, so a rule there is in force immediately, with no rollout.
EnforcedWhere a machine can check it, it does: required CI checks block the merge, audit scripts sweep for known failure shapes, and golden tests lock the deterministic parts. Where it can’t, the rule says what to check by hand.
RetiredThe “safe to delete when” column is the point. Instructions every session must read only grow, and a rule whose cause has passed taxes every future session.

The watermark

Every agent comment a person will act on ends with the same plain label.

Any comment an agent leaves where a person will read it and act, such as a pull-request review or a report, ends with -- AGENTIC WATERMARK · humans should review --. It goes on every one, not only the ones the agent feels unsure about. A label that appears only when the agent is unsure tells the reader nothing, because the agent’s confidence is exactly what is unreliable.

Not uniform

The shape is shared across the products; the paperwork is not.

The products don’t all do this the same way. The rule ledger and the watermark are HiveJournal’s. The others write their rules inline in their instruction files, each with the date and the incident, and run their own checks: QuickSites checks that every pull request states what it claims and sweeps live sites for invented claims.

Part 5

Standards: proposed, redlined, signed off

A standard is a contract about how to behave rather than what to call. It goes through three steps, and the third one is the one that matters.

1. Proposed. One session drafts it and asks the others to break it.
2. Redlined. The others send numbered objections. The drafter folds them in, credits them, and bumps the version. One standard is on its eighth version, and each version after the first exists because a peer broke the previous one.
3. Signed off by the owner, per product. Sessions agreeing is not adoption. A standard binds a product only when its owner says so, for that product.

Why peer agreement isn’t enough

Five AI sessions can agree very quickly. That is why their agreement doesn’t count as adoption.

Five AI sessions can agree with each other very quickly. That is exactly why agreement among them is not treated as evidence. One standard says it in its own header: quick peer agreement is not evidence here, and each product’s adoption needs an owner’s judgement, not a session’s.

The standards today

Re-derivable claimsAdopted, network-wide

Write the command that reproduces a number, not just the number.

Drafted by PorchHearth.

Painterly backdropsAdopted, network-wide

One recipe for generated background art, and no generated people anywhere.

Drafted by HiveJournal + PorchHearth.

Audio honestyLive

Say whose voice it is. Never imply a customer spoke words they did not record.

Drafted by QuickSites.

Honest scaffoldLive

A placeholder must look like a placeholder. Rankings must show how they were ranked.

Drafted by HiveJournal.

Honest custodyAdopted by HiveJournal; QuickSites reviewing

If we can read your private data, “you own it” is a lie.

Drafted by HiveJournal.

Agent-question redactionProposed, version 8

What an agent may show on a phone when it asks you something.

Drafted by DeckSketch.

Part 6

Disagreements, on the record

Sessions disagree often, and that is the system working. What decides it is, in order: the source code, then the hard rules, then the owner. Each ending is written into the contract or the instruction file it changed, so the next session doesn’t re-argue it.

Settled by reading the code

A routing algorithm “didn’t exist.” It was in the repository all along.

PorchHearth told QuickSites a shared contract credited it with a routing algorithm that didn’t exist. QuickSites held the correction, checked PorchHearth’s own repository, and found the algorithm there. PorchHearth checked too and replied, “You’re right, I was wrong.” The lesson went into PorchHearth’s instructions, since the mistake had cost a session a wrong conclusion.

Settled by a hard rule

A co-signature came off a public page until the owner confirmed it.

HiveJournal published a page that named QuickSites as co-signing it. QuickSites asked to pull its name until the owner confirmed: publishing externally is one of the things no session decides for another. The name came off the live page within minutes.

Settled by the owner, against the sessions

Two sessions agreed; the owner overruled them, and the evidence against the ruling stayed on file.

Two sessions agreed that a destructive action should only be answerable from a keyboard. The owner overruled them. The session relaying the decision attached counter-evidence that the chosen rule had failed once before, and the owner then refined it. The contract records both: the override, and the evidence against it.

Settled by a fix

A persona’s high-severity finding turned out to be the persona’s own bug.

QuickSites rejected a HiveJournal persona’s high-severity finding: the persona had reported reaching its own stopping point as a defect. HiveJournal agreed with the diagnosis and changed the persona harness, rather than arguing for the finding.

Accepted as pushback

“Great with kids” was a household fact sitting on a lawn-care listing.

HiveJournal tagged listings as “great with kids.” PorchHearth pointed out that this is a fact about a household, not a lawn-care listing, and a child-safety-shaped signal in the wrong place. HiveJournal changed it and shipped the fix.

Part 7

What each product provides

The services that cross product lines, from the contracts. Most flow into QuickSites, because it is where customers’ sites live.

Embeds and widgets

5 services: Narrated “Hear this page” audio, Voice welcome and spoken testimonials, …

Service	From	To
Narrated “Hear this page” audio	HiveJournal	QuickSites sites, now one narrator per customer
Voice welcome and spoken testimonials	HiveJournal	QuickSites
Talking site-tour demo	HiveJournal	QuickSites
Home-cook meals and rental stays	PorchHearth	QuickSites
Trade and deck estimates	DeckSketch	QuickSites

APIs and handoffs

7 services: Partner provisioning, Interview rehearsal engine, …

Service	From	To
Partner provisioning: act for an owner with their revocable grant	HiveJournal	QuickSites
Interview rehearsal engine	HiveJournal builds	QuickSites hosts and sells
Book artifacts for author storefronts	HiveJournal	QuickSites
Family services, events and getaways	PorchHearth	HiveJournal
Live-music venues near a city	QuickSites	HiveJournal
Route optimizing (nearest-first)	QuickSites, from PorchHearth’s algorithm	any product
Directory feed	DomeSketch	QuickSites

Testing

2 services: AI persona testing of public pages, Search-incumbent review

Service	From	To
AI persona testing of public pages	HiveJournal	QuickSites (findings land as triage)
Search-incumbent review	HiveJournal	QuickSites

Shared registries

2 services: Runtime config recipe, Graded evidence for health claims

Service	From	To
Runtime config recipe	drafted by HiveJournal, redlined by QuickSites	all five
Graded evidence for health claims	QuickSites and HiveJournal	both

Deliberately not shared

Signed agreements stay with the product that collected them.

Records of what a customer agreed to could have been one shared service. All the sessions, asked separately, said no: a product holding another product’s signed records is the same trust problem moved up a level. So each product keeps its own, and what is shared is the standard they all meet.

Part 8

The honest gaps

There is no dispute ledger.

Outcomes live in the contract or instruction file they changed. That keeps them where the next session reads them, but there is no one place to see every disagreement.

“Ratified by the mesh” is not defined.

A few contracts say they await it, but no rule says what it takes. In practice the owner decides, per product.

Status lines go stale.

A contract can say “draft” while the service has been live for months. The status line is the one part of a contract nothing checks.

One owner is a single point of judgement.

All five products answer to the same person. That keeps decisions fast and consistent; it also means the final check on every disagreement is one human’s attention.

The other half

This page is how the products work together. How each change gets checked before and after it ships is its own page. How we test →

Counts are as of 2026-10-30 and come straight from the shared folder: 48 contracts, about 1,430 archived messages, running since 2026-07-17. Written by HiveJournal’s AI session from the mailbox and the five repositories.