Capital Portal Runbook

Admins can

• Read every queue and record: firms, NDA agreements and acceptances, selling group, funding queues, ledger.
• Add and edit firms, with the Architect confirming any change that makes a release stale.
• Add selling group members, record their diligence, submit them for review, and credit a subscription to an admitted member.

Only the Architect can

• Approve and publish a release.
• Accept a subscription, log a wire, reconcile, extend, lapse, cancel, and close into the ledger.
• Draft, approve, activate and retire an NDA version, decide whether a version is material, and record organization NDA executions.
• Admit, suspend, reinstate and remove a selling group member; record an executed dealer agreement; clear or disqualify a Rule 506(d) questionnaire; change an admitted member's tracks.
• Confirm a firms change that makes approved or published releases stale; add extra statement items to a signing package.
• Override a screening block when issuing a data room share link. An admin who hits a block is escalated to the Architect.

A page says "Only the Architect can do this" when you press a button you cannot use. That is the control working, not a fault.

Steps (all API calls today)

1. Create the release and import the manifest. POST /api/finance/releases, then POST /releases/<tag>/manifest.
2. Upload the artifacts. POST /releases/<tag>/artifacts/<name>. Each file's hash is checked against the manifest.
3. Validate. POST /releases/<tag>/validate. This runs every check below and lists each blocker by code.
4. Approve (Architect). POST /releases/<tag>/approve.
5. Publish (Architect). POST /releases/<tag>/publish. A published manifest never changes. A failed publication exposes nothing partial.

What validation checks ?

• The manifest exists and is well formed; the edition marker is right (a working draft cannot be published as a released document).
• Every artifact is present and its hash matches.
• No unresolved price tokens; the pricing schedule exists, is approved, and its hash matches.
• Every legal prerequisite is cleared.
• The canon audit passed.
• The firms list has not changed since the release was built (FIRMS_CHANGED).

Onboarding steps

1. Profile, entity details if investing through an entity, and jurisdiction.
2. Non-disclosure agreement. The page does not show the agreement itself. It checks whether the NDA is on record and, if not, sends the investor to /finance/nda/, which returns them here after acceptance.
3. Accreditation basis and verification method.

The server decides whether a step is complete. The page only shows what the server reports.

Running the agreement (/admin/dr/nda/)

1. Draft (Architect). Paste the agreement exactly as it should read. A draft is inert: it records nothing and shows nothing.
2. Approve (Architect). The words are fixed for good. If an earlier version exists, state whether this one is material.
3. Activate (Architect). It becomes the agreement everything presents. Viewers are asked to accept it at their next entry.
4. Retire (Architect) when it should stop being offered. Acceptances stay on file.

Material or not. Material means everyone who accepted an earlier version accepts this one too. Not material means they stay covered. The answer is recorded with the approval and cannot be changed.

How people accept

• Portal. On /finance/nda/ after signing in. This counts everywhere.
• Data room. Inside a room after the emailed room code. This clears that room and also counts for the Portal.
• Staff grant. A staff-granted room session may be cleared by a staff-granted acceptance. It clears that room only and never counts toward the Portal or signing.

Old one-click acknowledgements in rooms stop counting once a version is active. They are left exactly as they are.

Where the NDA is enforced today

• built Data room content above the public tier.
• built Accepting in the Portal, and onboarding step 2 (hand-off).
• not yet Portal documents, signing packages (blocker NDA_NOT_ACCEPTED), and investor onboarding completion.
• not yet The public verify page still has its own NDA step; it is to be replaced by a hand-off.

Verification by track

• Rule 506(c). The Company verifies the investor itself: either its own review of income or net-worth documents or a third-party vendor. Letters from a broker-dealer, adviser, attorney or CPA exist in the database but are not switched on; the Architect turns them on if wanted.
• Regulation S. A non-U.S. person determination, a residence outside the U.S., the date of the investor's offshore-transaction attestation and of the no-directed-selling-efforts attestation, and the country of the wire account. The expectation is a wire from an account in the investor's own name at a non-U.S. institution unless the Architect directs otherwise.
• Both: identity verified, sanctions screening clear, and a reference to where the evidence is filed. The Portal stores the reference, never the documents.

Verifying an investor ?

1. Open Verifications and press Open a record. Enter the investor's email (they appear once they have signed in to the Portal), choose the offering, whether you are verifying the investor or one of their entities, and the method. The track comes from the offering.
2. Record what you checked: identity, the sanctions result, where the evidence is filed and the country of residence. On a Regulation S record, also the two attestation dates and the wire account country. The page lists what is still missing.
3. Press Make valid. The record is valid for 90 days from that day. The Portal sets the date; nobody types it. The record is then frozen.

• Renewal. Open a new record for the same investor, entity and offering before the old one expires. Making the new one valid replaces the old one in the same step. Use the Expiring within 30 days filter weekly.
• Sanctions. An admin can record not run, clear, review or hit. A hit or review belongs to the investor, not to one record: it revokes every valid record the investor has, blocks acceptance (SANCTIONS_NOT_CLEAR) and stays open even if the flagged record is withdrawn. Only the Architect closes the flag, with a reason, using Clear sanctions flag; only after that can the Architect change the result. Until then no new record for that investor can be made valid.
• Corrections. A valid record cannot be edited. An admin can withdraw a pending record; only the Architect can revoke a valid one. Then open a new record. Nothing is deleted and every step is in the record's history.
• Acceptance uses the newest valid, unexpired record for the investor, offering and track. An expired record blocks acceptance (VERIFICATION_EXPIRED).

Covered persons (Rule 506(d)) ?

Per offering: the issuer, directors, executive officers who take part, 20 percent owners, promoters, and any compensated solicitor, with a questionnaire, a refresh date and a status for each. The same registry applies to Regulation S as policy. A disqualified person suspends sales for that offering. Selling group members are covered persons too; their questionnaire status lives on their member record (§ 08).

Form D and state notices

The first sale event creates a planned initial Form D with a due date 15 days later. The event is acceptance by default, or receipt of funds if the offering is set that way. The Portal tracks and prepares the data; it does not file. An authorized filer or the filing agent files on EDGAR. State notices are a separate list per state.

• Issue. Blocked unless verification is in place, the release is published, and the pricing and release are unchanged since the package was built (PRICING_CHANGED_SINCE_ISSUE, RELEASE_CHANGED_SINCE_ISSUE).
• Send, refresh, void. POST /api/finance/signing/<id>/send, /refresh, /void. Only an issued or sent package can be voided.
• Evidence. The executed document and the certificate of completion are kept and can be retrieved for as long as the retention schedule says.

Adding and admitting a member (/admin/dr/members/)

1. Add a member (admin). Choose broker-dealer or introducer, the tracks, and a contact. It starts as an applicant.
2. Record diligence (admin). For a broker-dealer: CRD number, SEC file number, states registered, the date FINRA membership was checked and what it showed. For both: the date the Rule 506(d) questionnaire was received and its refresh date.
3. Submit for review (admin).
4. Executed agreement (Architect, broker-dealers). Record the version and date the member signed.
5. Clear the questionnaire (Architect).
6. Admit (Architect). The page lists what is still missing, and the database refuses admission until it is all there.

Crediting a subscription

On the Subscriptions credited tab, an admin enters the subscription number and picks an admitted member. The member must be admitted for the subscription's track. A rejected or withdrawn subscription cannot be credited. Recording a different member corrects the credit and the earlier one stays in the history. Crediting pays no one.

Suspending and removing

• A suspended member cannot be credited with anything new. If an admitted member's questionnaire stops being clear, the Portal suspends the member in the same step.
• Removal is final and the record stays on file. Tick for cause when it was a breach, so that warrants are forfeited when that step is built.

Five kinds of member (API only until the page is updated)

The registry now holds five kinds, and the Members page does not show the new ones yet; use /api/finance/members and /api/finance/covered-persons. A broker-dealer holds the licence. A registered representative (independent broker) is sponsored by a broker-dealer and needs its own CRD number, a FINRA or BrokerCheck review and the sponsor's written consent. A Regulation S intermediary is licensed outside the U.S., takes the Regulation S track only and gives a no-directed-selling undertaking. A placement agency needs a legal basis the Architect has approved; none is approved yet, so none can be admitted. An introducer stays unpaid.

• Every paid kind needs a cleared questionnaire, clear sanctions screening and a verified-until date that the Architect sets. Credit stops the day after that date, and the Architect renews it with one update. An introducer needs only a cleared questionnaire and a track; a sanctions hit or review still suspends it.
• Credit to a representative also needs its sponsor to be admitted, clear and in date. Suspend a broker-dealer and credit to every representative under it stops at once; reinstate it and credit resumes.
• A paid member must be linked to its covered-person row on the offering (POST /members/{key}/covered-person, the Architect's step, and permanent), and that row must be clear before a subscription credited to it can be accepted. Clearing a covered person, and recording a new questionnaire for one already cleared, are the Architect's too.
• A mistaken link is ended with POST /members/{key}/unlink-covered-person (Architect, with a reason); the row and history stay, and the right person can then be linked. A covered person added in error is withdrawn with POST /covered-persons/{id}/withdraw (Architect, with a reason); acceptance then ignores it. A person still linked must be unlinked first, and a disqualified person cannot be withdrawn.
• Removing a credit, or replacing the credit of a paid member, is the Architect's (a credit that can no longer be accepted, because its member lapsed or was removed, would otherwise strand the subscription). The row and its history stay.

Accept ?

On the Funding page, open Subscriptions to accept and press Check and accept next to a subscription. Choose the offering, the window and the amount due. Check runs every acceptance rule without accepting anything and lists what stands in the way, with a link to where each can be fixed; Accept runs them again on the server. Accepting (POST /funding/accept) checks every gate and, only if all clear, records the commitment, locks the price, starts the clock, and creates the first Form D task when the offering counts acceptance as the sale. The page then shows the bank reference and the deadline. The investor chose 10, 30 or 60 days to have funds in the receiving account ?.

Blockers you may see

Funds

• Procedure: wire instructions appear only inside the authenticated Portal, never by email, and any change to them is confirmed by a callback to a known number.
• Funds are accepted only from an account in the investor's own name. A third-party payment is refused and escalated.
• Log the wire from the funding's page (Log funds received: the payer's name and the amount as the bank shows them). If the amount equals the amount due and the payer is the investor, funds are received. Otherwise the row shows "to review" and Resolve the funds received offers accept or reject. Accept is allowed only for the exact amount from the investor's own name; if the name on the verified record is wrong, correct that record first.
• Procedure: agents, members and introducers never receive or touch funds. The Portal has no path that gives them any.

When funds do not arrive

• The past-due view lists subscriptions past their deadline. Nothing lapses by itself.
• Extend with a reason and a new deadline (UTC), Confirm lapse with a reason (offered only after the deadline), or Cancel with a reason, before the deadline only: after it the server refuses a cancel and the funding is lapsed instead, which counts toward the two-lapse cap. Neither a cancel nor a lapse is accepted while a wire is logged and unresolved: resolve the wire (accept or reject it) or arrange its return first. A lapse releases the price lock; a new subscription is at the price then in effect.
• The offering terms say funds returned after a lapse go back without interest within 10 business days unless a resubscription is accepted. The refund is made outside the Portal; the Portal only records the state change.

Close

Close and issue (on a funding with funds received) takes the units, the price per unit and the security class; the page shows units times price against the funds received as you type, and the server refuses any difference. It issues the securities to the ledger as a new row tied to the previous one. The ledger is append-only, with holder, class, units, price, closing date, legends and lot. GET /api/finance/ledger/holdings, /report and /export read it.

• A role can have several firms. A firm that leaves is marked former, never deleted. Keys never change and are never reused.
• Every change is recorded with who made it and the list's fingerprint afterwards.
• Stale releases. If a change would make an approved or published release stale, the page lists the releases and the Architect has to confirm. An admin cannot confirm it.
• The list is read by the OM session as a file at GET /api/finance/firms/export.

• Screens for releases, signing packages, the ledger and the audit log. Today these are API calls. (Funding has its screen; see § 09.)
• Funding, investor side: no investor page shows the bank reference or the wire instructions yet. The policy is that instructions are given only inside the investor's authenticated Portal account and never by email, but the page that does it is not built, so today staff need an arrangement for getting the reference to the investor safely.
• Routes and screens to record covered persons (Rule 506(d)), Form D filings and state notices.
• Verification: a re-check when an investor starts a subscription (it is checked at acceptance today), an expiry that flips a lapsed record to expired by itself (it already reads as expired and blocks acceptance), and letters from a broker-dealer, adviser, attorney or CPA if the Architect turns them on. A subscription does not say which entity is investing, so acceptance cannot yet match an entity record to the subscription; it reads the newest valid record for the investor, offering and track. A sanctions result recorded earlier is not required to be recent when a record is made valid.
• NDA enforcement at Portal documents, signing packages and onboarding completion; replacing the verify page's own NDA step.
• Selling group: the investor naming a member when subscribing; commission statements and the cash incentive plan; warrants as ledger events; the FINRA Rule 5123 package and the Form D compensation data; linking a member's NDA to admission.
• Investor withdrawal before acceptance (until built: written notice to the Company and an admin state change), state notice export for the filing agent, reminder emails, the preliminary edition, and a transfer agent role.
• Reg S intermediaries: not decided. No finder path exists for either track.
• Vetting: the AI assistant (research runs, the sanctions list matcher, report generation) and the links into the verification and selling group screens. See § 15.
• Admin assistant: asking the runbook, the triage view and drafting outbound text exist (§ 16). Record summaries are not built, and drafts are not canon-checked.

How it fits together ?

• Subject. A person or a firm, with a required compliance basis that cannot be changed. It can be linked, once, to an investor, an investor entity, a selling group member or a professional firm. Use public identifiers only (CRD, LEI, SEC file number), never a tax or government ID number.
• Engagement. One reason to vet one subject, numbered like ENG-2026-015. It starts at L1. Only one engagement can be live for a subject and purpose. An engagement can name a verification record or a selling group member it supports; this is a reference and changes nothing there.
• Finding. One thing found, with the source and the date it was retrieved, a proposed tier and the status of the matter. No source URL or no retrieval date makes it unconfirmed; an unconfirmed finding can only be rejected. A person accepts (at a tier) or rejects (with a note) every finding, and the decision is final. To correct one, reject it and add a new one.
• Closing. Needs every finding decided, a next-level assessment (L1: not warranted, recommended or required; L2: assessment complete, follow-up required or external investigator required) and an overall tier that is not below any accepted finding. It starts a seven-year retention period. A closed engagement is final.

Who does what ?

• Admins add subjects, open engagements at L1, add findings, accept or reject findings proposed at Tier 1 or 2, escalate to L2 once a finding proposed at Tier 2 or higher has been accepted at Tier 2 or higher, and close at Tier 1 or 2. An admin cannot accept a finding above the tier it was proposed at, and cannot accept their own finding at Tier 2 or higher: another admin or the Architect decides it.
• The Architect decides any finding proposed at Tier 3 (accepting, downgrading or rejecting), opens or escalates to L2 without a Tier 2 or 3 trigger, closes at Tier 3, and opens the next engagement for a subject whose earlier engagement closed at Tier 3 or with a required or follow-up determination (so an admin cannot supersede a serious outcome with a clean one).
• A Tier 2 or 3 accepted finding rules out "not warranted" at L1, and Tier 3 at L1 means "required". A Tier 3 finding cannot close as assessment complete.
• An accepted Tier 3 sanctions finding on an engagement that names a verification record shows a pointer to the existing step: record a sanctions hit on that verification. Nothing is recorded for you.

Using it

• Ask in a sentence, for example how to renew a verification or who closes a sanctions flag. Press Ctrl+Enter or Ask.
• The answer cites the chapters it used. Open the chapter and check it before you act. If the runbook does not cover the question, the assistant says so; it does not guess.
• Leave out investor names, emails, account numbers and ID numbers. A question containing an email address or a long number is refused and nothing is sent. Funding windows and similar short numbers are fine.
• It will not tell you that an Architect-only step is yours to take, and it gives no legal, tax or investment advice.

What needs attention?

• The button reads the work queues straight from the Portal and lists the ones with work in them, in a fixed order: open sanctions flags, funds that did not match, subscriptions past their funding deadline, vetting findings proposed at Tier 3, Form D filings due within seven days or late, expired verifications, subscriptions waiting for review, verifications in progress, selling group applicants, vetting findings waiting for a decision, covered persons overdue for refresh, selling group questionnaires overdue for refresh, and verifications expiring within 30 days.
• Each queue shows its count, how long the oldest item has waited or how overdue it is, who acts on it (admin, Architect or both), a link to its screen, or "No screen yet" where there is none (the step is API only, or, for Form D and covered persons, not built at all, so those two queues read zero until it is).
• The counts and the order are not produced by the AI. The AI only writes the short explanation of each queue and a summary of where to start, from this runbook. It is given counts and ages only: no names, emails, amounts, bank references or findings. If the explanation fails or you are at your daily limit, the counts still appear without it.
• The same counts are explained once and the explanation is reused for ten minutes, whoever presses the button, so pressing it again costs nothing. Each admin has 10 fresh explanations a day, with at least 30 seconds between them; past that, the counts still appear without an explanation. An empty list says "Nothing is waiting" and makes no AI call.

Draft a message

• Four templates: a due diligence request letter (to a vetting subject), a selling group follow-up (to a member), an investor verification request, and a funding reminder (for an accepted subscription waiting for funds). Pick the template, pick the record, tick what to ask for, and press Draft.
• The AI writes the wording around placeholders. It is never sent a name, email, date, amount or bank detail, and it is told to say nothing about Carbotura's business, pricing, returns or terms. The Portal fills the placeholders afterwards, on the server, from the record: the recipient's name, the reply date, the funding deadline. What the Portal cannot know is left as a marked field such as [SENDER NAME] or [DELIVERY INSTRUCTIONS] for you to fill in. A name on record that looks unusual (it contains a link, an address or a long number) is also left as a marked field, and the dialog says so. The funding deadline is stated with its time in UTC, so a late-evening deadline is not mistaken for the next day.
• The draft is yours to edit. The Portal sends nothing: copy it into your own email or letter. A funding reminder is built to state no amount or bank detail, and the template tells the writer to say that wire instructions are only in the investor's Portal account and are never sent or changed by email; read the draft to be sure it does. A past-due subscription gets no reminder: that is the Architect's call.
• A draft that contains an amount of money (in figures or in words such as thousand), a percentage, a link, an email address, account details or a promise is withheld, and so is one that uses a placeholder it was not offered. Em dashes, en dashes and tildes are replaced.
• Not canon-checked. The canon vocabulary gate does not run on drafts: the canon rules have one loader, which a Portal function cannot call, and a second hand-written copy is not allowed. Each draft says so. Read it as you would any outgoing message, and run the canon gate on anything that describes the business.
• Each admin has 20 drafts a day, inside the shared 40 requests a day. The log keeps the unmerged draft with the placeholders and the number of the record, never the name.

What is kept

• Every answer and explanation is logged, append-only, with who asked, the question (for an explanation, the queue counts that were sent), the model, the prompt version, a fingerprint of what was sent and the token counts. If the log write fails the answer is not shown. The text of a refused question is not kept.
• The log can be read through the API only: an admin gets their own recent questions and the Architect can get everyone's. There is no screen for it yet.
• Each admin has 40 assistant requests a day (questions, fresh explanations and drafts together; explanations are also capped at 10 and drafts at 20), and the Portal as a whole has 300. At the limit it says so and sends nothing.
• Answers are marked as AI-generated. They are a pointer into the runbook, not a ruling, and the runbook itself is what binds.