FICTITIOUS DOCUMENT — FORGE DEMO ONLY · specimen data built for a product demonstration · no real family, firm, fund, bank, or person is depicted

The capital-flow build — the whole conversation

This build ran attended, in the app, in one sitting — every word below is as it happened, including the machine narrating its own working steps in its longer replies.

Them

I'm Steven. I handle investments and cash flow for the office.

Here's the thing I do by hand every couple of weeks and hate.

Our private funds send us capital call notices — money we owe them by a date — and distribution notices, which is money coming back to us. They arrive as PDFs and they just pile up in my folder. Nobody has a single view of what's going out and what's coming in.

So every time someone asks me "can we cover the calls next month," I go through the folder one notice at a time and build the answer in my head.

Build me something that reads my folder and gives me one page: everything due out and everything coming in, in date order, with the fund, the entity, the amount, and how many days away it is. The thing I actually need to see at a glance is whether the money coming in lands before or after the money going out.

My notices are in office\steven\.

Forge

I'll check the catalog and your world's existing machines before designing anything.

Good — I have what I need. Now let's talk shape before I build anything.

I checked the catalog (engine/catalog/INDEX.md) and what's already installed — nothing covers this. money-dashboard is a monthly plan-vs-actual close, k1-roll-call is about tax forms, match-and-flag is cash recon between bank and GL. None of them read capital call / distribution notices and lay out a cash-flow timeline. This is a genuine new build, and I confirmed your notices (PDF + HTML pairs, plus the fund-commitments spine) extract cleanly enough to pull fund, entity, amount, and date reliably.

Let's pick a shape — this is quick to tweak either way, so don't overthink it:

Level 1 — The one-page timeline. Reads every notice in office/steven/, pulls fund, entity, amount, due/pay date, and type (call vs. distribution), and renders one page in date order with days-away for each line, plus a running net-cash line so you can see at a glance whether the money coming in lands before or after the money going out.

Level 2 — Level 1 + a coverage flag. Same page, but any stretch where outflows would put the running total negative before the next inflow arrives gets visibly flagged (red), so "can we cover next month's calls" is answered by a color, not arithmetic.

Level 3 — Level 2 + status tracking and by-entity/by-fund rollups. Notices get marked paid/received as they clear (so it accumulates truth over time instead of re-deriving everything from the folder each run), plus a view broken out by entity (since calls draw against different entities' cash) and by fund.

For someone doing this by hand every couple weeks just to answer "can we cover," Level 2 is the sweet spot — it directly answers your actual question (does money in beat money out) without you doing math. Level 3 is worth it if you also want to track which notices are still outstanding vs. settled. Which one, or want to mix pieces?

Them

Level 2, please.

The coverage flag is the whole reason I'd open this — "can we cover next month's calls" is literally the question I get asked, and I want it answered by a color, not by me doing arithmetic.

Skip the status tracking from Level 3. We don't keep a payment record anywhere — nothing in my folder says whether a call has actually been paid or a distribution has landed — so a paid/received column would sit empty and I'd end up not trusting the page. Better it tells me what's scheduled and lets me confirm the rest myself.

Forge

Three quick things — these are the decisions that actually determine whether the flag tells the truth, so worth nailing down before I build:

1. Per-entity or one combined total? Your calls and distributions don't all draw from the same pocket — per the fund schedule, Cormorant IV and Windham Credit calls hit the Ellencourt 2012 Descendants Trust, Blackford III and Stillwater hit Wrenfield Holdings LLC, and Harrow Point RE II hits Kestrel Lane LLC. A distribution landing in the Trust doesn't cover a call drawn on Wrenfield LLC. I'd run the coverage math per entity (with an all-up total underneath for the big picture) — otherwise the flag can say "covered" when one entity is actually short. Sound right?

2. Starting cash balance, or purely relative? I don't see an actual bank balance anywhere in your files, so the default is a relative running total — it starts at zero and just tracks "net of calls and distributions from today forward per entity," which directly answers "does the money coming in outpace the money going out" without needing your real balance. If you ever want to plug in an actual starting cash figure per entity, that's an easy add later — but I'd skip it for now unless you have that number handy.

3. What happens to a notice once it's handled? Since there's no paid/received tracking, a call whose due date has passed will just sit there looking overdue forever unless it leaves the folder. Simplest: once you've actually wired a call or a distribution has landed, you drop the file out of office\steven\ (or into a subfolder like office\steven\done\ if you'd rather keep them). The page always just reflects what's currently in the folder. Good with that, or would you rather the page auto-fade anything past its date instead of relying on you to move the file?

Them

1. Per entity, with the all-up total underneath. You're right that a distribution landing in the Trust doesn't cover a call drawn on Wrenfield Holdings — and honestly the per-entity view is the whole point. If the combined number looks fine while one entity is short, that's exactly the thing I'd want the page to catch and I'd never see it myself.

2. Relative running total. There's no bank balance in my folder and I'd rather you not go hunting for one in someone else's — Robert's the one who holds the statements. Net of calls and distributions from today forward, per entity, is the answer to my actual question. If I ever want real balances plugged in we can do it later.

3. I'll move the file out — into office\steven\done\ — and the page reflects what's in the folder.

One thing though: don't auto-fade anything past its date. If a call is overdue and still sitting in my folder, that's the single most important thing on the page and it should get louder, not quieter. Fading by date would hide the exact problem I built this to catch.

Forge

All confirmed. Now I'll stamp the machine. Let me set up the todo list to track this build.

Good — I'll delete the placeholder READMEs and template's own README, and drop in real content instead.

Now let's write agents.md, the source of truth.

Now the generated humans.md twin.

Now the BACKLOG/CHANGELOG/SESSIONLOG placeholders.

bg/README.md is already generic and fine as-is. Let's fill the three logs.

Now let's write the SKILL.md and the reference doc for field extraction.

Now the reference doc on notice fields.

Now the four step files, plus a notice-record template asset.

Now the render step, following the insurance-schedule/match-and-flag pattern with the mandatory fiction-safety banner and correct link depths.

Now let's validate the SKILL.md frontmatter structurally.

Skill validates. Now let's actually execute the machine on Steven's real notices.

No .txt files yet — good, I'll extract each PDF to text beside it, per the read-only-on-sources rule (a .txt extract is read-support, not a change to the notice itself, same as the insurance-schedule pattern).

All 7 documents classified: 5 notices recognized (3 capital calls, 2 distributions), 2 skipped as not-notices (CPA cover letter, IC memo). Now writing the notice records.

Now I'll fill in the title, custom styles, header, and content.

Now updating agents.md's Views block to confirm it's accurate, then running the validation gates.

Views block already matches. Now running the validation gates.

All gates pass clean. Now carding the machine onto the home board.

Now writing the card fragment.

Home board is carded and verified clean. Now committing this work and reporting back to Steven.

Capital Flow is built and saved. It's a folder called capital-flow/ at the world root, cardable from Home now, that reads office/steven/ and gives you the one page you asked for.

What it found in your folder right now: 5 notices — 3 calls (Cormorant IV $9M due 8/4, Blackford III $7M due 8/7, Harrow Point RE II $6M due 8/11) and 2 distributions (Stillwater $2.25M and Windham Credit $1.4M, both paying 8/14). It skipped two other PDFs sitting in there — the CPA cover letter and the IC memo — since neither is a call or distribution notice.

The answer to "can we cover next month's calls": no, not from what's currently scheduled. All three entities go short — the Trust drops to −$9,000,000 on 8/4, Wrenfield Holdings to −$7,000,000 on 8/7, and Kestrel Lane to −$6,000,000 on 8/11 with no distribution scheduled to help it at all. The two distributions land on 8/14, after every call is already due, so they only partly claw the Trust and Wrenfield Holdings back — Kestrel Lane never gets an offset from anything in the folder.

Going forward: drop a new notice PDF straight into office/steven/ and ask me to refresh the page, or move a handled one into office/steven/done/ and it drops off on the next run. It never goes looking for a real bank balance anywhere else, and it'll never quietly fade an overdue notice — that's exactly the case it's built to shout about.

Take a look at the page yourself — if anything's off, or you'd rather it looked different, just say so and I'll change it.

See: Capital Flow · Timeline