The Portfolio Operating System

The shape

14 ventures sit in the registry. 12 of them have a live product. They are grouped in three: 6 flagship, 4 in the lab, 4 applied science.

One operator. No employees. The counts on this page are read out of the same registry file this website builds from, so they cannot drift from what you see on the ventures page.

The loop

Strategist finds → Builder builds → Shipper ships → Chief of Staff keeps state honest.

That is the whole engine, and it runs overnight. Around it sit the specialised loops that feed it: a roadmapper that takes early-stage ventures from spec to working product, a measurement owner, an organic-growth owner, a sourcing loop and a conversion loop at the two ends of the sales funnel, a brand loop that stages posts for a human to publish, and a nightly self-heal pass that closes stale rows, refreshes the top priority and flags loops that have stopped producing.

Every loop ends in a shipped artifact or a decision, and writes its own state back. Nothing ends in a status update.

Four queues, one consumer

Four producers write four ranked backlogs. One builder reads all four, every run, in a fixed order: the portfolio backlog, the venture backlog, the measurement backlog, and the organic-growth backlog. Items are deduplicated by ID — the same ID across two queues is one build, not two.

This is scar tissue, not architecture. Before the contract existed, four producers wrote four queues and the builder read one of them. Ventures were skipped five runs in a row, an entire queue was never consumed, and statuses had to be reconciled by digging through the disk. The rule was written the day that was discovered.

The handover ledger

One append-only file is the handshake. The builder appends a line for every item it handled, in the same run: date, item ID, which queue it came from, which project, and one of BUILT PARTIAL ESCALATED KILLED, plus a note.

Every producer reads that ledger before rewriting its own queue. On a rewrite, any previously listed unbuilt item must either stay listed or be explicitly killed with a dated reason. A silent drop counts as a handover failure, not as housekeeping.

Five hard gates

Five classes of action the system may never take by itself. It writes the code, then flags and waits for a human.

1. Money going live — payment wiring, pricing changes, payouts, refunds.
2. Auth and secrets — never create, rotate or commit a credential. Write the code that consumes an environment variable; leave the value to the human.
3. External sends and posting — email, DMs, social posts, anything that contacts a third party.
4. Scheduled tasks — creating, disabling or rescheduling them.
5. Destructive or irreversible infrastructure — deleting data, DNS and domain changes, production migrations.

Everything else — backends, APIs, data pipelines, product features — is buildable without asking. The gates are narrow on purpose: a system that must ask about everything gets ignored, and a system that asks about nothing eventually spends your money.

The envelope

Gate 3 has exactly one approved exception, and the exception is where most of the discipline lives. Automated outbound is permitted only inside an envelope with every edge written down: one lead type only, the top two tiers only, only to an address that has verified as valid or is published on the company's own website — never an inferred address, never a catch-all domain — every message anchored to a specific quoted finding, a hard daily cap, a stop-loss that halts the lane after two bounces in a day, and every automated send tagged as automated in the outreach ledger.

Everything outside those edges is drafted by the machine and sent by a human. The envelope is the answer to "how much autonomy?" — not a number, a boundary you can read.

The handshake that stops half-built work shipping

The shipper sweeps every repository roughly every fifteen minutes and used to commit whatever it found — including a tree a builder was still writing into. The fix is one file. A builder drops a marker in the repository root before it edits. While that marker is fresh the shipper skips the repository. When the builder finishes — success or failure — it overwrites the marker with the word done, and the work publishes on the next sweep.

Two details carry the weight. Completion is signalled by writing, never by deleting, because a sandboxed builder can rewrite a file but cannot always remove one. And a marker older than forty-five minutes is treated as a crashed build and published anyway — so the worst case is a delay, never work stranded on a disk nobody looks at.

Three engines, reused

Most of the "projects" are instances of one of three engines. A compliance engine: a rule corpus plus audit logic. A signal engine: scrapers into a signal file, a free dashboard on top, a paid interface behind it. A marketing engine: audit, research, generate, publish, distribute, measure.

Build the engine once and every project that reuses it is close to free. That, rather than working harder, is the only honest explanation for the number at the top of this page.

The disciplines

• Verify first. Check a checkable premise before building on it. A premise proved false and closed with evidence is a successful run, not a wasted one — several of the best outcomes on record are exactly that.
• Never fabricate. Not a build, not a number, not a date, not a test result. The floor rule says it plainly: escalation counts as progress; never fabricate to hit the floor.
• Prove by execution. A completed item reports how many assertions actually ran and what they asserted. "Should work" is not a result.
• Kill before add. Prefer compounding actions over busywork; do not pad the backlog.
• Self-audit before publishing. Public marketing copy is run against a rule pack before it ships. This page was audited that way before it was published, and the first draft did not pass.

Cadence

Not everything runs every day, and pretending otherwise is how portfolios rot. Projects are tiered. The revenue engine takes several build slots every run. The next tier takes one slot each, every run. The rest rotate on Mondays, Wednesdays and Fridays. Two early-stage ventures hold a reserved slot every run regardless of tier, because they are the ones that quietly get skipped.

The floor is a minimum, not a cap: capacity freed by a fast run flows upward to the highest-scoring work. Skipping a reserved slot requires a named reason in the build log — a skip without one is recorded as a breach.