Filling the three homes

Part 1 sorted your answers into three homes. Skills hold how you do things. A database holds your numbers. The brain holds what happened and why. If you ran the sorting kit, you split a few bundles and wired the homes to point at each other.

That fixes what you already have. New answers show up every day, in every call, email, chat and conversation with your agent, and they need a way in. Each home has its own front door, and the right way to fill one is the wrong way to fill another.

My own three homes fill in three very different ways.

My lead pipeline fills a database. Every inquiry, from a form, an email or a call, becomes a row in a table that already knows what a lead looks like. Each row carries the original message's ID, so the same lead can't land twice, and a column pointing at the customer's page in my brain. It has been quietly reliable for months, because nothing gets in without fitting the shape.

My skills fill when I work. When my agent and I get a job done right, the agent writes the method down or, much more often, fixes the skill it already has. In the month before I started this issue (mid-September to mid-October), my main agent edited existing skills more than 150 times and created one new skill.

My brain fills from everywhere: meeting transcripts, conversations, the newsletters I subscribe to. It's the busiest home and the hardest to keep clean. On September 30 it took about 12,700 automatic facts in under an hour, most of them stamped with the wrong date. I'll come back to that.

Then there's the call that fed none of them properly. In July a customer phoned about a job. In five minutes I said my production rates out loud for the first time (a number), explained why I sell a site walk-through before I quote (a method), and promised a quote early the next week (history). The rates ended up typed into a skill. The customer's brain page got a fragment of transcript. The database that's supposed to hold every quote got no row at all. The call was captured, technically. It just never went through the right doors.

The problem

Most capture advice starts from the source: how do I capture meetings, how do I capture email. That's backwards. The home decides how something gets captured. A number has to arrive in a shape the database can check. A procedure has to arrive as a skill your agent can find and trigger. A piece of history has to arrive with a date, a source and a person attached, or it's noise.

Capture tools mostly ignore that. A recorder hands you a transcript, built-in memory writes whatever it noticed into one place, and everything lands wherever is easiest to write, with the number, the method and the reason still stuck together.

Matt Van Horn, a builder who writes about agents, found this when his agent's automatic memory hit 218 files. Much of it wasn't junk. It was misfiled: "About 39% was durable, useful lessons, but each one was tied to exactly one skill. A fix for a specific tool, sitting in a global memory that the tool never reads" (as quoted here; his summary). Those were good captures that came in through the wrong door.

Capturing numbers: the schema is the front door

A database only protects your numbers if it knows what a correct number looks like before the number arrives. That's the schema: the tables, the columns, and the rules each column enforces. Design it first, with your agent's help, and capture second. Do it the other way around and you get a dumping ground with a column named notes2.

What a well-designed table does for capture:

• One table per kind of thing. Orders, order lines, suppliers, quotes, hours. A row is one of those things, never a mix.
• Types and rules the database enforces. SQLite is loose about types by default, but a STRICT table refuses a value it can't store as the declared type and raises an error instead. Add NOT NULL for fields that must exist and CHECK rules for allowed values (a status can only be one of five words). A bad capture fails loudly at the door instead of sitting quietly in your books.
• A unique key from the source. The order number, the invoice number, the email's message ID. Make it unique, and the second run of the same import can't create a second copy. This one rule is most of what keeps my lead table clean.
• Real links between tables. Order lines point at orders, and orders point at suppliers. In SQLite, foreign key checks are off by default and have to be turned on for each connection, so tell your import script to turn them on.
• Where it came from, and why. Every row records its source, when it happened and when it was captured, plus a link to the note that explains it. That's Part 1's wiring, built into the table.
• A log of every run. Items seen, items new, items rejected. When a run reports zero from a stream that normally has twenty, you notice.

Then the capture itself should be code, not conversation. GBrain's guide on this, "Code for Data, LLMs for Judgment", explains why: a model following a rule "follows the rule for the first 10 items, then drops a link on item 11." So pull numbers from the system that owns them (the marketplace export, the accounting API, the order confirmation email). Have your agent write a small import script once, check its first run by hand, and schedule it. The pull budget, checkpoint and exception log for that script are in the October 2 ingestion issue.

Numbers that come from a conversation, like a price a supplier tells you on the phone, still go through the same door. The agent proposes a row, and the import step loads it once you've approved it. A number never gets written into a skill or a note as the live value.

Getting a number in clean is half the job. The other half is agreeing on what it means, which is what the October 16 weekly's definitions file is for. The schema keeps bad numbers out, and the definitions file keeps a good number from being read two different ways.

Capturing procedures: use your harness's skill builder

All four harnesses we cover now have an official way to build skills. Here's what each one offers, from its own docs:

• Hermes has /learn, which turns "anything you can describe" into a skill: a workflow you just walked through, a folder, a URL, or pasted notes. The agent also writes and edits skills on its own, including during a background review after a turn. Set skills.write_approval to true, and every skill write is staged for your approval instead of saved directly.
• Claude Code skills follow the open Agent Skills format. Its official skill-creator plugin, a separate install, runs test prompts against a skill and compares results with and without it, so you can see whether it actually helps.
• Codex bundles a skill-creator you invoke with $skill-creator, and a Record & Replay feature that watches you do a workflow and drafts a skill from the demonstration. Its docs make a point worth repeating: Codex picks skills by their description, so "front-load the key use case and trigger words so a host can still match the skill if descriptions are shortened."
• OpenClaw has a Skill Workshop. The agent "saves a procedure after hard multi-step work and fixes a learned skill that misled it," archives learned skills nobody has used in 30 days, and saves the previous version before every change. Changes apply right away, so the safety net is undo, not approval.

Whichever builder you use, five rules apply:

1. Capture right after you do the job correctly once, in the same session, while the steps and the mistakes are still on screen. Not from memory a week later.
2. Edit before you create. Most new lessons belong in a skill you already have. My 150-to-1 month wasn't an accident. A new skill for every lesson is how you end up with hundreds of them.
3. Write the description as "use when." It's what your agent reads to decide whether to load the skill at all.
4. Keep numbers, dates and stories out. The skill says which table holds the rate and where the reason is written down. The rate goes in the database, and the story goes in the brain. My July rates sitting inside a skill is this mistake.
5. Test that it triggers. Open a fresh session and ask for the job the way you normally would, without naming the skill. If the agent doesn't load it, fix the description.

Capturing history: the brain needs a write contract

The brain is where automatic capture works best, because history arrives constantly and most of it is words. It's also where sloppy capture does the most damage. The fix is a write contract: a short set of rules every write follows, whatever tool or stream it came from.

GBrain ships these contracts as skills, and they're the best example I know. Its ingest skill promises that every fact written "carries an inline [Source: ...] citation with date and provenance," that every mentioned person or company gets a link back from their own page, that raw sources are preserved, and that the current summary on a page is "rewritten with current best understanding, never appended to." Its filing rules settle where things go: "The PRIMARY SUBJECT of the content determines where it goes. Not the format, not the source, not the skill that's running." And every page has two parts: a current summary on top and a dated timeline underneath that only grows.

You don't need GBrain to use the idea. The answer card from Part 0's kit is a write contract too: a question, a status, who confirmed it, when, and the sources. What matters is that every write into the brain follows the same rules:

• It's attached to someone or something: a person, customer, supplier, job or decision. If the agent can't say what a fact is about, it doesn't get kept.
• It has two dates: when it happened and when it was captured. The capture date never stands in for the real one.
• It cites its source, ideally with the exact quote, and the original stays somewhere the agent can read but not change.
• It updates before it adds. If the page already says this, the agent adds the new source to it. If the new fact contradicts the page, it flags both.
• It cites numbers instead of holding them. The note says the price changed and why, and points at the database row for the price itself.

My September 30 runaway is what happens when one write path skips the contract. A repair job re-saved about 7,000 pages, each save triggered automatic fact extraction, and in under an hour the brain had about 12,700 new facts. Most were dated the day they were captured, and about 9,600 weren't attached to anyone. The contract existed. That background path just didn't follow it. We turned extraction off, cleaned up from backups, and brought it back nine days later with three gates: a bar for what's worth keeping, dates taken from the content instead of the clock, and a 14-page test run first, which came back with zero facts stamped with the test day's date.

For meetings, GBrain's meeting ingestion skill has the rule I'd give anyone: treat "recorder auto-summaries" as "CLAIMS, not facts," and check anything surprising against the transcript before it touches a person's page. Speaker labels deserve the same suspicion. My recorder gets them wrong often enough that I never let a promise get assigned to a person without reading the quote.

A word on recording: I transcribe my work calls, and you should check two things before you do. First, your state's law. Justia's 50-state survey says most states require only one person on the call to consent and a smaller group requires everyone. For calls across state lines it suggests following the strictest state's rule, since courts don't agree on which law applies. Second, what your recorder does with the recording. In August a federal judge let several privacy claims against Otter.ai go forward, finding the plaintiffs had plausibly alleged that Otter "independently collects, retains, and uses communications for its own commercial purposes" (order). A July suit against Granola makes similar allegations (complaint). Neither case establishes liability. Turn off model training if your recorder allows it, and tell people you're recording.

The three doors on one page

My July call, through the right doors

That five-minute call should have produced:

• A proposed quote row in the bid database, with the customer, the job, what they said about its size, the range I gave on the phone, and a link to the call.
• Proposed rate rows, sourced to the call and marked as planning numbers until real job results replace them.
• A proposed edit to my pricing skill: thickness decides the day count, so sell the walk-through before the number, and read the rate from the table.
• A dated note on the customer's page: what they want, the quote I promised and when, and what I learned about the property, with the transcript as the source.

That's four items through three doors, approved in one sitting. The paid kit below builds that.

Without becoming the librarian

Part 1 promised capture without turning you into a full-time librarian, so here's my own score. On October 18 my brain's inbox held 65 captures that nobody ever filed, the oldest from April. Capture worked. Filing didn't.

The doors fix most of that, because each one files as it captures. The row lands in its table, the edit lands in its skill, and the note lands on the customer's page. What's left for you is a review, and it has to stay small. Turn on one stream at a time. Review the changes and the exceptions, not everything. Once a stream has run clean for a month, let its routine items through without you, the same way the October 2 promotion ladder moves a job from agent to script. New suppliers, procedure changes and promises to customers stay gated for good.

What I run, and what else is out there

I run Hermes, GBrain, SQLite, a call recorder, and Gmail through Google's command line tool. Everything else below comes from each vendor's own pages, read in October 2026, untested by me. The question for any tool is which door it can feed.

• Into the database: your existing exports and APIs come first. For email, Claude's Gmail connector can search and draft, and on eligible plans ChatGPT can run a task when a new Gmail message arrives. Hermes documents a Google Workspace skill and a separate mailbox just for the agent.
• Into skills: the builders above. One more idea worth borrowing is Slack's official MCP server: your team chat's answered "how do I" threads are skill material.
• Into the brain: meeting recorders that let an agent read your meetings, usually on a paid plan. Granola (API on the $14 Business plan), Fireflies, Otter (MCP even on the free plan, API and webhooks on Enterprise), Fathom and Jamie (Pro plan and up) all offer a way out for transcripts. On eligible Workspace plans, Gemini in Google Meet saves notes to the organizer's Drive. For Discord, discrawl archives a server to a local database, and it's what our Discord runs on.
• Your harness's built-in memory doesn't split by type. Hermes can hold memory saves for approval, Claude Code's auto memory is on by default, and Codex's memories are off by default. Decide whether yours goes through the doors above or stays off.

Where this goes for our members

• Order email into the buy sheet. One member's agent reads order confirmation emails and expands each buy into full rows, logs anything it can't match to an exception list, and reruns until the list is empty. That's the database door done right. The next step is a unique key on order number so a rerun can never double a buy.
• Lead and buy reasons. A member's agent now warns them about brands that went badly before. The numbers live in tables; the reasons belong in the brain with a pointer from the row.
• Spreadsheets that drift. A member's monthly process kept changing from one month to the next. That's a procedure that never went through the skill door. Run it once correctly with the agent and turn that session into a skill.
• Chat history. A member found that saving whole conversations beat saving single messages. Through the doors, answered how-to threads become skill edits and the why threads become notes.

Next in the series is shape: what a page about a person, customer or supplier should look like once all of this starts landing on it.

The playbook: the capture kit

Operators: this kit builds the three doors. It assumes you've done Part 1's sorting kit, or at least know where your three homes are. Steps 1 through 7 work in any harness. Step 6 has the GBrain version. Nothing captured here becomes live until you approve it: numbers sit as proposed rows, notes sit in an inbox, and skill edits wait for you where your harness supports that (step 3 says which ones do).

Step 1: Inventory how each home fills today

Paste this into your harness:

Audit how knowledge gets into my three homes. Read only; change nothing. Homes: my database [path or name], my skills (wherever you load them from), and my brain or notes folder [path]. For each home, tell me every way something gets written to it (a script, a schedule, you during a chat, me by hand, an automatic memory feature) and whether each write path checks anything before writing. Count writes over the last 30 days only where a log or file history shows them, name the evidence, and say "no record" where there isn't one. Don't estimate. Then check these specifically: (1) database tables without a unique key from the source system, without type rules, or without a source column; (2) skills that contain prices, rates, dates or incident stories; (3) brain pages or memory entries that hold a live number, have no date, or don't say who they're about; (4) any number, procedure or decision from my last 20 calls, emails or chats that didn't end up in any home. Rank the gaps by what each would cost me if it went wrong.

Fix the top item from list 4 first. That's the July-call problem in your own business.

Step 2: The database door: schema, then import

Paste:

Help me design a database schema for [orders / purchases / quotes / hours]. Look at [my spreadsheet or export] and propose tables before building anything. Rules: one table per kind of thing; SQLite STRICT tables; NOT NULL on required fields; CHECK rules on fields with a fixed list of values; money stored as whole cents in INTEGER columns; a UNIQUE key taken from the source system (order number, invoice number, email message ID); foreign keys between related tables; on every table of captured records, columns for source, happened_on (or effective_on), captured_on, and why_ref (a link to the note that explains the row). If a value can change over time (a price, a rate), keep every version as its own row with an effective date, allow only one approved row per item and date, and add a view that returns only the current approved value; my agent reads live values from that view and nowhere else. Add an ingest_runs table that records each import: when, which stream, completed or failed, items seen, new, rejected, and the error. Show me the CREATE TABLE statements and explain each rule in one line. Wait for my OK.

A few tables that come out of that prompt look like this (made up, and tested in SQLite):

PRAGMA foreign_keys = ON;

CREATE TABLE suppliers (
  id    INTEGER PRIMARY KEY,
  name  TEXT NOT NULL UNIQUE
) STRICT;

CREATE TABLE supplier_prices (
  id              INTEGER PRIMARY KEY,
  supplier_id     INTEGER NOT NULL REFERENCES suppliers(id),
  sku             TEXT NOT NULL,
  unit_cost_cents INTEGER NOT NULL CHECK (unit_cost_cents >= 0),  -- money as whole cents
  effective_on    TEXT NOT NULL,          -- when the price took effect
  source          TEXT NOT NULL,          -- email link, export file, call transcript
  source_key      TEXT NOT NULL UNIQUE,   -- invoice number + line, email ID; blocks duplicates
  captured_on     TEXT NOT NULL,
  status          TEXT NOT NULL CHECK (status IN ('proposed','approved','rejected')),
  why_ref         TEXT                    -- path to the note explaining a change
) STRICT;

-- At most one approved price per supplier, SKU and start date
CREATE UNIQUE INDEX one_approved_price ON supplier_prices (supplier_id, sku, effective_on)
  WHERE status = 'approved';

-- The only place the agent reads live prices from: the latest approved price already in effect
CREATE VIEW current_prices AS
SELECT p.* FROM supplier_prices p
WHERE p.status = 'approved'
  AND p.effective_on <= date('now')
  AND p.effective_on = (
    SELECT max(x.effective_on) FROM supplier_prices x
    WHERE x.supplier_id = p.supplier_id AND x.sku = p.sku
      AND x.status = 'approved' AND x.effective_on <= date('now'));

CREATE TABLE ingest_runs (
  id          INTEGER PRIMARY KEY,
  stream      TEXT NOT NULL,
  started_at  TEXT NOT NULL,
  status      TEXT NOT NULL CHECK (status IN ('completed','failed')),
  seen        INTEGER NOT NULL DEFAULT 0,
  new         INTEGER NOT NULL DEFAULT 0,
  rejected    INTEGER NOT NULL DEFAULT 0,
  error       TEXT
) STRICT;

The status column is your staging. Captured numbers come in as proposed, and the agent reads live numbers only from current_prices. A price change is a new row, not an edit: the old price stays as history, the new one waits as proposed, and when you approve it, the view switches to it on its effective date. Two approved prices for the same item and day get refused, so the agent can never find two "current" answers. Money goes in as whole cents (4.40 becomes 440) because decimal math in a database drifts by fractions of a cent. If you buy by the case and sell by the unit, say which one the column means.

Then have the agent write the import script:

Write an import script for [stream] into these tables. It must: turn on foreign keys for its connection; read only from the source; skip rows whose source_key already exists; insert everything else as status 'proposed', including a changed price for an item that already has one (as a new row with its own effective date, never an edit to the old row); show me each proposed change next to the current approved value; write rejects (type errors, missing fields, unknown products) to an exception log with the reason; and record a row in ingest_runs for every run. If it can't reach or read the source, record the run as 'failed' with the error, never as 'completed' with zero items. Run it once on last month's data, then show me counts next to the counts from the original export so I can check nothing was dropped.

Check three numbers by hand against figures you already know before you schedule it. Questions get a read-only connection, and only the import script writes.

Step 3: The skill door: your harness's builder

Use the builder your harness ships:

Right after you finish a job correctly, say:

Turn what we just did into a skill, or an edit to an existing one if one covers this job. Check my existing skills first and prefer editing. Description: one line starting with "Use when," naming the job the way I'd ask for it. Body: the steps in order, the checks that caught mistakes today, and what to do when something looks off. Don't include any prices, rates, dates, names or the story of today's session. Instead, name the table that holds each number and the brain page or note that holds the background. Show me the draft or the diff and wait for my OK before saving.

Then test it: open a fresh session, ask for the job in your normal words, and confirm the skill loads. If it doesn't, rewrite the description, not the body.

Once a month, run Part 1's skill diet prompt. Anything dated or numeric that crept back in gets moved out.

Step 4: The brain door: a write contract

Put this in whatever file your harness always loads (AGENTS.md, CLAUDE.md, or your Hermes or OpenClaw memory):

## Writing to the brain
- Every write is about one person, customer, supplier, job or decision.
  If you can't say which, don't write it.
- Every fact gets happened_on (from the source; "unknown" if it doesn't
  say) and captured_on. Never fill in captured_on as happened_on when
  the source doesn't give a date.
- Every fact cites its source with a link and, for anything surprising,
  the exact quote. Originals go to [raw folder] and are never edited.
- Search before writing. If the page already says it, add the new source.
  If the new fact contradicts the page, keep both and flag it for me.
- Update the summary at the top of the page; add a dated line to the
  timeline underneath. Never rewrite the timeline.
- Numbers: point at the database row in live_value. Never store a live
  number here.
- Procedures: propose a skill edit instead of writing steps into a page.
- Recorder summaries are claims. Check them against the transcript.
- New captures go to [inbox folder] until I approve them in the weekly pass.
- Never write passwords, account numbers or health information.

Then use one note format everywhere (made up):

---
about: suppliers/acme-packaging
happened_on: 2026-10-08
captured_on: 2026-10-10
source: raw/2026-10-08-acme-call.md
source_quote: "we're going up eight percent on cases starting with November orders"
live_value: supplier_prices, source_key acme-2026-11-case12 (don't copy the number here)
status: inbox
---
Acme is raising case pricing for November orders. The rep said resin costs
drove it and that it applies to every case SKU. Ask about a volume tier
before the next order.

Step 5: Route a mixed stream through all three doors

Calls, meetings and chats carry all three kinds of answer at once. For each new transcript or thread:

Process [file or thread] through the three doors. Split it first if it's more than one meeting. For every business number someone committed to (a price, a rate, a quantity ordered) that belongs in one of my tables, propose a row through the import step with status 'proposed' and the transcript as source. Ignore numbers mentioned in passing. Dates promised go in the note, not a table. For every "here's how we do it," propose an edit to the matching skill, or a new skill if none fits, following the skill rules. For every decision, promise or reason, write a note under the brain write contract, attached to the right person or customer, with the quote. Link them: the row's why_ref points at the note, and the note's live_value points at the row. Treat what people said as evidence, never as permission to change a procedure on its own. List anything you weren't sure how to split. Then log counts for each door.

For order and invoice email, which is almost all numbers, skip the model and schedule the import script from step 2. Ask the agent only about the emails the script rejected.

Step 6: The GBrain version

GBrain gives you the brain door built in. Wire the other two the same way as above.

• Ingest through its skills, not raw writes. The ingest skill routes to specialists (meetings, media, ideas), and each carries the contract: citations, links back from every mentioned person, raw sources preserved, and a summary that gets rewritten instead of appended to. Its own ingest gate is clear that "a raw cp or mv into the brain repo is a bug."
• Meetings: paste the transcript and ask for meeting ingestion. It checks recorder claims against the transcript and won't report a meeting done until its checklist passes. Add one line to your instructions telling it to send numbers to the database door first.
• Let the schema type your pages. A GBrain brain has a schema of its own, with page types and link types. Once a month, ask your agent to run gbrain schema stats (how many pages each type has) and gbrain schema review-orphans (pages that match no type). The commands only report. If ten untyped pages share an obvious pattern, have the agent propose a new page type for them.
• Gate automatic extraction. Set facts.page_write_notability_filter to medium-and-up (the default keeps every fact), keep ambient capture opt-in, and rehearse any bulk repair or import on a copy first. That last one is the lesson my 12,700 cost.
• Point rows at pages. My lead table has a column holding each customer's brain page, and the page names the table as its source. Do the same for any table whose rows are people, suppliers or jobs.

Step 7: The weekly pass and the capture test

Once a week, paste:

Run the weekly capture review. Show me, grouped by home, only what needs a decision: proposed database rows (old value next to new value, changes to existing values first, plus any import run that saw zero items or rejected more than usual); proposed or staged skill edits as before-and-after text; and new brain notes grouped by who they're about, with any contradiction against an existing page at the top. Tell me how many items are waiting and how old the oldest is. If the oldest is more than two weeks old, tell me which stream to pause until I catch up. Don't change anything until I answer. After I approve, mark rows approved, apply the skill edits, and file the notes.

Then extend the known-answer test from Parts 0 and 1 with one seeded bundle. Do it once per new stream, before you turn the stream on. Paste:

Run the seeded capture test for [stream] in a sandbox. Never touch my real homes. 1) Make a sandbox: a copy of my database file, a scratch skills folder with a copy of the skill this stream would edit, and a scratch notes folder. Point the import script and every write at the sandbox only, and show me the paths before you start. 2) Write a fake source item in the stream's format (a call transcript or an email) from "Test Supply Co" to "Test Customer." It should contain a price of $4.40 a case on SKU TEST-1 effective yesterday, a procedure change ("count the cases before you sign for the delivery"), and a promise ("we'll send the revised quote by Friday"). Add Test Supply Co to the sandbox suppliers table first. 3) Run each check below and give me a table of check, expected, actual, PASS or FAIL. 4) When you're done, delete only the sandbox, and confirm my real files haven't changed since you started.

Checks: (a) Capture: one proposed price row with the source and a why_ref, one proposed edit to the copied skill that names the table instead of the price, and one inbox note about Test Customer with happened_on taken from the item, the quote, and live_value pointing at the row. (b) Before approval: current_prices doesn't show $4.40, and a fresh session asked about the TEST-1 price says there's no approved price and mentions the pending one. (c) Approve all three, then ask a fresh session for the price, the procedure and the promise. Each answer names its home: the view, the skill and the note. (d) Run the same item through again. Nothing new appears, and the run log shows 0 new. (e) Send a second fake item moving the price to $4.75 effective today. You get one new proposed row shown next to the approved $4.40, a flag on the note, and still exactly one row in current_prices. (f) Point the import at a source that doesn't exist (rename the sandbox file, or use a mailbox label that isn't there) and run it. The run log shows "failed" with the error, not "completed" with zero.

If all six pass, turn the stream on. If any check fails, the stream stays off until a rerun passes. Paste the results table into the brain as the stream's test record; next month, the same prompt tells you whether anything drifted.

What not to do

• Don't let a conversation write a live number. Numbers go through the import step, every time.
• Don't create a new skill for every lesson. Edit the one that covers the job.
• Don't write to the brain without a date and a subject. An orphan fact never comes up when you ask about the customer.
• Don't build the schema after the data arrives. Design first, then capture.
• Don't record people who don't know.

Steal this

Tonight, run the step 1 inventory and look at list 4: the numbers, procedures and decisions from your last 20 calls and emails that never landed anywhere. Pick the most expensive one and send it through its door: a schema and import for a number, the skill builder for a procedure, or the write contract for a decision. Then run the seeded test on that stream before you let it run on its own.

Hit reply and tell me which door was missing in your setup. I read every one, and the hard ones go into this series.