The Draft Loop — Elevator

Draft proposed

draft_s3_v1 · §3 compliance & capital

req_capital

"The firm maintains £500k of regulatory capital in a segregated client account at HSBC, audited quarterly. Reporting is overseen by the CFO…"

req_ownership

"The firm is wholly owned by Acme Holdings Ltd, a Gibraltar-incorporated entity. No foreign control. Beneficial ownership is held by the founders…"

req_dr_plan

[placeholder: insert DR plan summary — q_dr_plan still open]

↓ DraftFeedback

DraftFeedback

df_001 · markdown diff · 2 comments

comment · CFO

"The £500k figure was correct for Q1 but we're now reporting Q2. Update to £280k and flag the concern — see ev_cap_2."

comment · compliance

"Ownership wording is fine. Please cross-link the corporate structure diagram in §1.2."

↓ revised

Draft revised approved

draft_s3_v2 · revised from v1

req_capital

"The firm currently holds £280k of regulatory capital, segregated at HSBC. A concern is open with the CFO regarding the GIBFIN 12.4 minimum (see ev_cap_2)…"

req_ownership

"The firm is wholly owned by Acme Holdings Ltd (see §1.2 corporate structure diagram). No foreign control. Beneficial ownership held by the founders…"

req_dr_plan

"DR plan documented in §3.4. Quarterly tabletop. Recovery time objective: 4 hours. Verified against last incident response, Mar 2026…"

The architecture permits drafting

This Section belongs to an internal_draft Deliverable whose architecture has been confirmed. Two Requirements are evidenced. The third has a credible drafting path but still needs an explicit placeholder.

The server-derived Section status becomes draftable_with_gaps. That is permission to compose honestly—not permission to hide what is missing.

Draft v1

The composer reads the Section, its Requirements, the Evidence supporting each, and the user responses on any Questions in scope. Then it writes prose.

Every paragraph carries a covered_requirements entry: which Requirement does this paragraph address, and is the coverage substantive or a placeholder? The DR plan paragraph is honest — it's a placeholder, marked as such. Nothing pretends to be more solid than it is.

User edits in Elevator

The CFO and Compliance lead open Elevator's rich-text editor. They correct the figure, preserve the table structure, add a missing cross-link, and leave a comment for context. DraftFeedback stores the original and modified markdown plus the comments.

Nothing silently mutates the approved source. The feedback is queued for the next round, where the composer sees it alongside the Requirements and current Evidence.

Draft v2

Next round, draft-composer reads the feedback alongside the original Requirements. It produces v2. The corrected capital figure is in — and the concern is flagged inline, so the regulator-facing prose admits what the Evidence row already says.

The cross-link to §1.2 is in. The DR plan placeholder is now substantive — a Question on DR was answered in the same round, and the composer absorbed the answer into the prose.

Approved

The team reviews v2. No new feedback. Status flips to approved. Until something upstream changes—a Requirement re-interpreted, Evidence invalidated, or a user response corrected—this Draft is the Section's current prose and the internal Deliverable can become ready_for_review.

External counsel's Word comments do not come back through DraftFeedback. They use a separate ReviewCycle, with annotation-level replies, amendments, sync, and verification.