Flip 360 Commission Platform
🔒 Internal Steerco paper
Confidential · not for external distribution
Audience: Steerco members · AI agent team · incoming investors under NDA only
Contains candid working-session record with hazards named
PMO flying minutes

PMO Director working session with AI agent team (CTO / EA / SA / CIMA / CX hats)

📅 2026-07-04 · Chair: Ms Carla Oliver, PMO Director
Purpose: Reconcile the Flip360 business model against Vol 5 v1.1 canonical, close open questions on the platform take rate, membership fee, Foundation distribution architecture, Community Manager role, and end-customer consent capture. Produce the ratification artefact for tabling at SC#3. No code is committed against session resolutions until Steerco ratification; a docs-only reconciliation memo is committed as evidence of the working session's output.

Executive summary

On 04 July 2026, following the closure of Sprint AB (Vol-2 MVP Evidence Pack + programme-level /crm/mvp-evidence route deployed to production), the Chair convened a working session with the AI agent team to reconcile five materially open model questions before authorising any downstream engineering work. The session moved through fifteen agenda items covering CRM readiness, contact-onboarding compliance, business model correction, Community Manager territorial architecture, Foundation distribution mechanism, platform take rate reconciliation, membership fee, and referral consent capture. Two of the session's most consequential ideas — the postcode-exclusive Community Manager territory model and the platform-earnings-redistribution architecture — are recorded as Mr Punter's originating contributions, brought into the session by the Chair. The design, build, and implementation of both remain the responsibility of the PMO Tech Workstream (WS2) under Ms Oliver's accountable ownership per Steerco Decision D110. The session produced a single canonical ratification artefact — the v1.2 reconciliation memo committed at ca7da3c — which is tabled at SC#3 (2026-07-06) for formal ratification. No code has been written against the session resolutions; the standing "no forward-fixing" discipline is preserved.

Meeting particulars

Date
2026-07-04
Session type
PMO Director working session with AI agent team (CTO / EA / SA / CIMA / CX hats)
Chair
Ms Carla Oliver, PMO Director
Attendees
• Ms Carla Oliver — PMO Director · WS2 Lead (accountable) · Chair
• AI agent team — Tech Workstream (WS2) delivery — CTO / EA / SA / CIMA / CX hats under delegated authority from Chair
Apologies / not present
• Mr Mathew Punter (Product Owner, Founder) — contributions relayed by Chair from prior founder conversations and this session's working-through
• Ms Corrina Marven (WS1 Lead) — to be briefed on outcomes by Chair before SC#3
Quorum
Not applicable — PMO Director working session between formal Steercos. Resolutions tagged DEFERRED-TO-STEERCO tabled at SC#3 (2026-07-06) for formal ratification.

Reference documents

Agenda · discussion · resolutions

AGENDA ITEM 1

Sprint AB closure and pilot-launch-gate call

Raised by: PMO
Discussion
Session opened against the state established at HEAD 8722167 (Sprint AB shipped): the Vol-2 MVP is engineering-complete on the CRM operator surface. All three EA Constitutional rules (Rule 1 court-defensibility, Rule 2 money proven, Rule 3 Evidence Pack discipline) are discharged in production code with commit anchors that resolve on GitHub and render at cosaiflip360.org. The programme-level /crm/mvp-evidence route is live and returns HTTP 200. The Chair sought and received AI agent team confirmation that the engineering critical path for the MVP has closed and that pilot-launch is now a governance decision, not an engineering decision.
Resolution RESOLVED
Vol-2 MVP is engineering-complete on the CRM operator surface. Pilot-launch gate is at the PMO desk, not the engineering desk. Sprint AA (Stripe Connect) remains commercially-blocked pending PMO greenlight — this is not an engineering constraint.
Action items
Owner Due Task
Chair 2026-07-06 (SC#3) Table pilot-launch-gate readiness to SC#3 for formal ratification
AGENDA ITEM 2

CRM readiness to receive Mr Punter's contact onboarding

Raised by: PMO
Discussion
Chair posed the question: is the CRM ready for Mr Punter to begin importing his contacts? AI agent team surveyed the codebase and confirmed: single-contact create/read/update/archive/restore is fully wired against D1 with audit-safe soft-delete. No bulk CSV import surface exists, and no de-duplication or bulk-tag surface exists. Chair pushed back on the initial framing (which had assumed bulk import was the right feature) — see Agenda Item 4 for the material correction.
Options considered
A — Founder-friendly: Mr Punter hand-keys first 5–20 contacts in one session with the CRM as-is; use as a UX discovery event✓ CHOSEN
Pros: Founder in operator seat; real feedback drives what to build next; no scope creep; ships today
Cons: Not scalable past ~30 contacts
B — Bulk-import sprint first, then hand over✗ REJECTED
Pros: Unblocks a founder with 200+ contacts
Cons: Assumes we know what he needs before he's used the system; risks building wrong feature
C — Hybrid: hand-key first, sprint if untenable⏸ DEFERRED
Pros: Learns from real use before committing engineering
Cons: Requires PMO discipline to hold the line on Option A first
Resolution RESOLVED
CRM is ready to receive Mr Punter's first tranche of contacts via single-entry today. Bulk-import surface deferred pending real-use discovery of Mr Punter's actual needs. Chair to schedule the hand-key session with Mr Punter as the discovery event that scopes any future bulk-import sprint.
Action items
Owner Due Task
Chair This week Schedule hand-key onboarding session with Mr Punter; observe friction points; capture findings for future bulk-import scoping
AGENDA ITEM 3

Compliance framing for Mr Punter's TSC contact list — Car Park A/B/C metaphor

Raised by: Ms Oliver (Chair)
Discussion
Chair introduced the Car Park A/B/C metaphor from Mr Punter's working shorthand. On first framing, this was misread by the AI agent team as a consent-ladder inside a single database (one contact record moving through consent stages). Chair corrected the framing on second turn: Car Park A/B/C represents THREE SEPARATE DATABASES — Car Park A is Mr Punter's existing TSC (The Savings Centre) customer database (~10,000 contacts), Car Park B is a subset who explicitly consent to hear about Flip360, Car Park C is the further subset who explicitly consent to be marketed to by Flip360. The compliance principle: contacts do not move databases without explicit consent at each gate, and each move is timestamped, logged, and revocable. This is not a marketing feature — it is the Spam Act 2003 + Privacy Act 1988 compliance architecture.
Resolution RESOLVED
Car Park A/B/C compliance architecture ratified as the governing consent framework for any onboarding of Mr Punter's TSC list. Mr Punter's TSC customers are not, and never become without explicit consent, Flip360 customers. The Flip360 database is built one voluntary crossing at a time.
Attribution
Car Park A/B/C is Mr Punter's operating shorthand from prior conversations, brought into the session by the Chair.
Action items
Owner Due Task
Chair Before SC#3 Draft the PMO compliance one-pager on Spam Act 2003 + Privacy Act 1988 as they apply to Flip360, referencing the Car Park A/B/C architecture. File as docs/pmo/compliance/contact-marketing-v1.md.
AGENDA ITEM 4

Business model correction — Flip360 is B2B2C, not B2C

Raised by: Mr Punter (PO)
Discussion
Chair relayed Mr Punter's framing of the actual business model, which materially corrected the AI agent team's implicit assumption. Flip360 is not a platform that acquires end-customers — Flip360's paying members are the SERVICE PROVIDERS (mortgage brokers, insurance brokers, financial planners, tax accountants, real estate agents, buyers agents, building inspectors, conveyancers). The commissionable event is the PROVIDER-TO-PROVIDER REFERRAL between two Flip360 members. The end customer (Sally) is a party to the transaction but is not a Flip360 account holder in any meaningful sense — she remains the customer of her referring provider, and only her chosen fields (via consent — see Agenda Item 13) enter Flip360's ambit. The external payer (home loan lender in Sally's case) is entirely outside the platform. AI agent team acknowledged this was a material correction to its previous framing and updated its model understanding accordingly.
Resolution RESOLVED
Flip360's business model is a B2B2C provider-to-provider referral network. Paying members = providers. Commissionable event = provider-to-provider referral. End customer = beneficiary of a referral, not a Flip360 account holder. Mr Punter's TSC list, in this frame, is most useful for PROVIDER RECRUITMENT (finding brokers/accountants/planners inside TSC who should become Flip360 providers), not for customer acquisition.
Attribution
Mr Punter's originating framing of the business model, brought into the session by the Chair and materially corrective to the AI agent team's prior assumption.
Action items
Owner Due Task
AI agent team Sprint AI Update all downstream artefacts (investor brief v2.0, financial model, onboarding wizard) to reflect B2B2C framing, not B2C. Explicitly reframe CUSTOMER contact records in the CRM as referral-audit-trail records, not marketing targets.
AGENDA ITEM 5

Onboarding wizard design — provider-set referral fees with RRP-guided slider

Raised by: Mr Punter (PO)
Discussion
Chair relayed Mr Punter's CIMA/CX-hat proposal for the provider onboarding wizard: a multi-step flow where each provider (a) ticks the services they provide from a per-vertical list, (b) sets their referral fee for each service using a slider ($0–$2,500) with a platform-provided Recommended Retail Price (RRP) guide analogous to Airbnb's host pricing suggestions or Uber's dynamic pricing hints, (c) sees transparent disclosure of the platform take, (d) nominates community organisations for their share of the Foundation pool, (e) provides ABN + bank details. Mr Punter's explicit design intent: the Flip360 provider is like an Airbnb host — they control what they pay for a referral, informed but not dictated by platform guidance. The AI agent team confirmed that per-vertical RRP data already exists in src/data/market-sizing.ts (Q×F×P methodology with per-profession derivation notes) and can be extracted into a first-class data file for the wizard.
Resolution DEFERRED TO SC#3
Onboarding wizard scope confirmed: services multi-select → per-service fee slider with RRP guide → transparent take disclosure → community nomination → ABN/bank. Per-vertical RRP data to be extracted from market-sizing.ts into a new data file at src/data/referral-fee-rrp.ts. Wizard route to be built at /onboard/* in Sprint AC.
Attribution
Mr Punter's originating design idea (fee slider + RRP guide + Airbnb-analogous provider agency), brought into the session by the Chair.
Action items
Owner Due Task
AI agent team (WS2) Sprint AC (post-SC#3 ratification) Extract per-vertical RRP structure into src/data/referral-fee-rrp.ts; build /onboard/* wizard
AGENDA ITEM 6

Community Manager (CM) role with postcode-exclusive territory

Raised by: Mr Punter (PO)
Discussion
Chair relayed Mr Punter's proposal for a new platform role: the Community Manager (CM). CMs are assigned exclusive geographic territories defined by postcode clusters. Within their territory, the CM has the exclusive right to recruit Flip360 providers. Mr Punter's design ethos, explicitly stated: "we don't want the platform to be extractive of local communities, we want it to be reciprocal." The CM role is the mechanism by which that ethos becomes structurally enforced rather than merely marketed. The CM has skin in the game locally: they are a named human accountable for a defined geography, they earn from the territory's success, and (per Agenda Item 7) they influence where community distribution lands inside their postcodes. The AI agent team wearing the CIMA hat modelled three CM compensation options: Option 1 (per-referral cut from platform take), Option 2 (separate salary from Flip360), Option 3 (per-provider activation bonus + share of annual membership fee + community-distribution curation authority, no per-referral cut). The AI agent team recommended Option 3 as structurally coherent with the reciprocal ethos — because Options 1 and 2 make the CM a middleman with volume incentive, which recreates the extractive dynamic at the local level, whereas Option 3 makes the CM a steward whose income aligns with sustained territory health. The AI agent team wearing the EA hat flagged four governance obligations that PMO must own before CM #1 is recruited: (a) Territory Charter (rules of the road, max postcodes, dispute resolution); (b) CM Accountability Framework (performance SLA, misconduct/removal); (c) Community Distribution Governance (curation criteria, conflict-of-interest declarations, provider veto rights); (d) Legal status determination (contractor vs agent vs franchisee — tax, super, workers comp, vicarious liability differ).
Options considered
Compensation Option 1 — Per-referral cut from platform take✗ REJECTED
Pros: Volume-aligned
Cons: Recreates extractive dynamic locally; misaligned with ethos
Compensation Option 2 — Separate salary from Flip360✗ REJECTED
Pros: Clean separation
Cons: Two money flows; CM economically dependent on Flip360; not "skin in the game"
Compensation Option 3 — Activation bonus + membership share + community direction rights, no per-referral cut✓ CHOSEN
Pros: Aligns with sustained territory health, not transaction volume; CM is community-embedded steward, not sales rep; ethos-coherent
Cons: Requires PMO governance framework before CM#1
Resolution DEFERRED TO SC#3
The Community Manager role is adopted as a new platform role. Territory = postcode cluster, exclusive to one CM. Compensation = Option 3 (activation bonus + share of $1,500 annual membership + community-distribution curation authority; no per-referral cut). Governance obligations (Territory Charter, Accountability Framework, Community Distribution Governance, legal status determination) are added to the PMO backlog as prerequisites to CM#1 recruitment.
Attribution
Mr Punter's original idea, brought into the session by the Chair. Mr Punter is the originator of both (a) the postcode-exclusive territory concept and (b) the reciprocal-not-extractive design ethos that shapes the CM role. The AI agent team's contribution was reconciling the CM proposal against Vol 5 v1.1 canonical, modelling the three compensation options, and identifying the four governance obligations. Design, build, and implementation of the CM role in the platform is the responsibility of the PMO Tech Workstream (WS2) under the Chair's accountable ownership per Steerco Decision D110.
Action items
Owner Due Task
Chair (PMO) Before Sprint AF Draft Territory Charter, CM Accountability Framework, Community Distribution Governance policy
Chair (PMO) Before CM#1 recruitment Engage legal counsel on CM legal status (contractor vs agent vs franchisee) and vicarious liability posture
AI agent team (WS2) Sprint AF (post-Steerco ratification) Build CM territory model + /cm/* operator dashboard + provider-CM association
AGENDA ITEM 7

Platform earnings redistribution to community — the Flip360 Foundation architecture

Raised by: Mr Punter (PO)
Discussion
Chair relayed Mr Punter's design for how Flip360 platform earnings return to the communities the platform operates inside. Vol 5 v1.1 Chapter 4.5 (New in v1.1) already captures Mr Punter's originating architecture: a separate legal entity — the Flip 360 Foundation, structured as a DGR under Australian charity law — receives a structural share of every dollar of net platform revenue in perpetuity by structural deed, not by board discretion, and distributes that pool to registered Australian charities and community organisations. This is not corporate social responsibility. This is not a "% pledge" line in marketing copy. It is the platform's structural design. In this session, Mr Punter's architecture was evolved from Vol 5 v1.1's 70/30 split (70% affiliate-nominated / 30% Foundation-board-chosen) to an 80/20 split (80% local / 20% national democratic vote). Mr Punter's explicit intent for the 20% national tranche: "1 vote per member for what money goes to where — like a political party election or something democratic like that." The AI agent team wearing the EA hat flagged four hazards on the democratic mechanism (vote capture / astroturfing, cause polarisation, regulatory exposure under fundraising licences and DGR compliance, democracy-of-the-loudest) and proposed mitigations in-design (activity gate for voting, Foundation-board-curated shortlist, proportional split not winner-take-all, editorial policy excluding primary political/religious/ideological causes). The AI agent team wearing the CIMA hat modelled the numbers at 100 / 1,000 / 10,000 provider scale. At scale-up (1,000 providers), the Foundation pool becomes $1.26M/year, with the national vote tranche $252k/year = $63k per quarterly vote. At full scale (10,000 providers), the Foundation pool is $12.6M/year and the quarterly vote pool is $630k — mainstream-media territory that makes the Foundation self-marketing. Chair took the 80% local tranche further: rather than each affiliate individually nominating their share directly to any org (Vol 5 v1.1 canonical), the 80% local pool is directed by providers within a territory nominating from a CM-CURATED SHORTLIST of ~20 vetted local orgs. This gives CMs meaningful curation authority (a real form of political capital in the territory) without giving them personal fiduciary weight over the distribution itself — the individual provider making the nomination remains the party the ACNC/OAIC will look at, not the CM.
Options considered
Local pool Option A — CM alone directs the 80%✗ REJECTED
Pros: Simple; territorial coherence
Cons: Excessive fiduciary weight on CMs; DGR / Corporations Act 601FC risk at material pool sizes
Local pool Option B — Provider nominates from CM-curated shortlist of ~20 vetted local orgs✓ CHOSEN
Pros: Provider agency preserved; CM curation authority is real; ACNC/OAIC fiduciary weight sits with individual provider; regulator-safe
Cons: Requires CM to maintain a curated shortlist
Local pool Option C — Provider nominates by default, CM directs residual after 30 days✗ REJECTED
Pros: Fallback for inactive providers
Cons: Two mechanisms in one bucket; edge cases; harder to explain
Resolution DEFERRED TO SC#3
The Foundation distribution architecture is evolved from Vol 5 v1.1 to v1.2 as follows: (a) 80% local / 20% national split (up from 70/30 in v1.1); (b) 80% local tranche = provider-nominated from CM-curated shortlist of ~20 vetted local orgs (Option B); (c) 20% national tranche = quarterly democratic vote by active platform members, one vote per active provider, Foundation-board-curated shortlist of 5 causes per quarter with 7-day objection window, proportional split to top 3; (d) activity gate for voting = ≥1 paid referral in last 90 days (recommended, pending SC#3 confirm); (e) mitigations in-design for all four EA-identified hazards.
Attribution
Mr Punter is the originator of the platform-earnings-redistribution architecture. Vol 5 v1.1 Chapter 4.5 codifies his originating design. This session evolved the distribution split from 70/30 to 80/20 with the democratic-vote mechanism for the 20% national tranche, on Mr Punter's explicit direction ("1 vote per member … like a political party election or something democratic like that"). The AI agent team's contribution was hazard identification, mitigation design, financial modelling at three scale points, and reconciliation against Vol 5 v1.1 canonical. Design, build, and implementation of the Foundation redistribution mechanism in the platform is the responsibility of the PMO Tech Workstream (WS2) under the Chair's accountable ownership per Steerco Decision D110.
Action items
Owner Due Task
Chair (PMO) Before Sprint AG Engage legal counsel on democratic-vote mechanism to confirm it does not trigger fundraising licence requirements or DGR non-compliance (Vol 5 v1.1's board-chosen model was specifically designed inside the safe harbour; v1.2's democratic model requires legal review)
Chair (PMO) Before Sprint AG Foundation entity incorporation + DGR registration with ACNC — precondition for Foundation pool to be tax-effective and distributed lawfully
Chair (PMO) Before Sprint AD Deed of Trust between Flip360 Pty Ltd and Flip360 Foundation Ltd — establishes the 14% flow-through as agent-collected fiduciary funds, not Flip360 revenue
AI agent team (WS2) Sprint AG (post-Steerco ratification and Foundation incorporation) Build community distribution mechanic — Foundation payouts to community orgs from Foundation-held account
AGENDA ITEM 8

Platform take rate reconciliation — 1% operational + 14% Foundation flow-through

Raised by: PMO
Discussion
A material inconsistency was surfaced by the AI agent team: the Chair had initially proposed a 15% platform take rate for the take-rate model. The AI agent team, on searching the codebase for existing decisions, found that sweetener.tsx, walkthrough.tsx, and by implication the memorandum all commit to a 1% (one per cent) platform fee framed to members as "cost recovery, not profit extraction." A silent overwrite from 1% to 15% was flagged as a potential Constitutional violation — the codebase, sweetener, and walkthrough would contradict each other if the change went in without formal decision. Chair paused, considered, and directed the reconciliation to a HYBRID model that preserves both the v1.0 codebase commitment AND the Vol 5 v1.1 "50% to Foundation" ambition. The hybrid: 1% is the platform operational fee (revenue to Flip360, keeps the v1.0 story intact); 14% is the Foundation levy that flows straight through to the Foundation entity, never touching Flip360's operating account, accounted as agent-collected liability under a Deed of Trust. The combined visible take is 15%. This produces cleaner tax posture (Flip360 pays tax only on 1% + membership fees; Foundation pays no tax as DGR; no commingling), cleaner regulatory posture (the 14% is a structural payment, not a discretionary donation), and a materially stronger marketing story ("15% sits between you and the sender — but only 1% keeps our lights on. The other 14% goes directly to your community.").
Options considered
Take rate Option A — Keep 1% flat (v1.0 codebase state)✗ REJECTED
Pros: Preserves "cost recovery not extraction" framing
Cons: Undercapitalises Flip360 given Foundation obligations; contradicts Vol 5 v1.1 "50% to Foundation" ambition
Take rate Option B — Move to 15% flat (Chair's initial proposal)✗ REJECTED
Pros: Fully capitalises platform + Foundation
Cons: Silent overwrite of v1.0 codebase commitment; recreates extractive dynamic; breaks marketing framing
Take rate Option C — Hybrid 1% operational + 14% Foundation flow-through✓ CHOSEN
Pros: Preserves v1.0 "cost recovery" framing at platform level; delivers Vol 5 v1.1 Foundation ambition; cleaner tax + regulatory posture; stronger marketing story
Cons: Requires Deed of Trust + separate Foundation bank account; more complex ledger
Resolution DEFERRED TO SC#3
The platform take rate is the hybrid Option C: 1% operational (Flip360 P&L revenue) + 14% Foundation levy (flow-through, never Flip360 revenue, accounted as agent-collected liability). Combined visible take = 15%. The v1.0 codebase commitment to 1% is preserved; the Vol 5 v1.1 "50% to Foundation" ambition is delivered via the 14% flow-through mechanism.
Action items
Owner Due Task
Chair (PMO) Before Sprint AD Deed of Trust drafting — see Agenda Item 7
AI agent team (WS2) Sprint AD (post-ratification) Foundation ledger extension — four-leg accrual (net to earner / Foundation levy 14% / platform 1% / membership stream separately), 80/20 split at Foundation entity
AGENDA ITEM 9

Annual provider membership fee — $1,500

Raised by: Ms Oliver (Chair)
Discussion
Chair set the annual provider membership fee at $1,500/year, a 25% increase over the v1.0 codebase figure of $1,200/year. AI agent team surfaced the delta as a strategic price point, not an inflation adjustment. Rationale: below-competitor pricing vs professional association dues in most Australian services verticals ($800–$3,000 range); anchors Flip360 as premium infrastructure for referral-earning professionals, not low-commitment SaaS; break-even for a provider is one referral of $250+ received per year, a low bar.
Options considered
Fee Option A — Hold at $1,200 (v1.0 codebase)✗ REJECTED
Pros: No delta from committed state
Cons: May undercapitalise
Fee Option B — Move to $1,500✓ CHOSEN
Pros: Premium anchor; strong margin
Cons: Requires updating sweetener/memorandum/simulator
Fee Option C — Variable by vertical⏸ DEFERRED
Pros: Fair to lower-fee verticals
Cons: Complex to market; defer to v2.0
Resolution DEFERRED TO SC#3
Annual provider membership fee set at $1,500/year, uniform across all verticals for v1.2. Variable-by-vertical deferred to v2.0. Billing structure (annual up-front vs monthly with 12-month lock-in) deferred to SC#3.
Action items
Owner Due Task
AI agent team (WS2) Sprint AI Update sweetener.tsx, /investors/memorandum, and /investors/financial-model to $1,500 membership fee
AGENDA ITEM 10

End-customer referral consent capture — the Sally-shaped surface

Raised by: PMO
Discussion
Session unearthed a compliance gap not covered in Vol 5 v1.1: the mechanic by which the end customer (Sally in the working example) consents to being referred from one Flip360 provider to another. Under Privacy Act 1988 APP 6 (use or disclosure of personal information) and Spam Act 2003 (consent for commercial electronic messages), the referring provider cannot lawfully share the customer's contact details with the receiving provider, and the receiving provider cannot lawfully contact the customer, without explicit consent. Vol 5 v1.1 is silent on where and how that consent is captured. The AI agent team wearing the SA hat proposed a public, Flip360-branded referral consent capture surface at /consent/:token. Mechanic: (a) referring provider selects "refer this customer" inside CRM; (b) Flip360 shows matching providers with referral fees (RRP-guided); (c) referring provider picks receiver, Flip360 generates signed referral token; (d) referring provider sends customer a message from their own channels containing token; (e) customer clicks link, lands on Flip360-branded consent page with plain-language options (what fields will be shared, which provider will receive, what contact method, duration of consent, revocability); (f) customer consents, event written to consent_events table with timestamp/IP/wording, hash-chained under Rule 1; (g) only after consent event is the customer's chosen fields surfaced to receiving provider. The AI agent team wearing the EA hat proposed this as a Rule 4 amendment to the EA Constitution: "Customer consent for third-party disclosure is captured, signed, and independently retrievable from the transaction it authorises."
Resolution DEFERRED TO SC#3
Referral consent capture at /consent/:token is added to the v1.2 scope as the compliance surface unearthed this session. Proposed as EA Constitution Rule 4 for formal ratification at SC#3.
Action items
Owner Due Task
AI agent team (WS2) Sprint AE (post-ratification) Build /consent/:token public referral consent capture surface with signed audit trail; add consent_events table to schema
AI agent team (EA hat) Before SC#3 Draft Rule 4 amendment to EA Constitution for formal Steerco ratification
AGENDA ITEM 11

Investor brief v2.0 scope — three-way "what's in it for..." structure

Raised by: Ms Oliver (Chair)
Discussion
Chair directed that the existing /investors, /investors/memorandum, and /investors/financial-model surfaces (2,883 lines of live code at HEAD ca7da3c) are to be extended, not replaced, to reflect the v1.2 model. The extended brief must include three explicit "what's in it for..." tabs: (a) For Investors — LTV/CAC, revenue per member under hybrid take, path to Foundation-sustainability, IPO case; (b) For Community Managers — activation bonus + membership share economics, territory income projections, community-direction political capital; (c) For Providers — break-even calculation on $1,500 membership, expected referral flow, per-vertical RRP tables. The Chair also directed that the investor brief must NOT assume a single flat fee across verticals — the RRP data extracted from market-sizing.ts (per-profession Q×F×P methodology) must feed both the investor brief tables AND the onboarding wizard slider (see Agenda Item 5).
Resolution DEFERRED TO SC#3
Investor brief v2.0 to extend /investors surface additively with three-way "what's in it for..." tabs, live RRP tables per vertical, CM economics, hybrid take rate model, and Foundation architecture. Parallel-run discipline: v1 preserved until Steerco signs off v2.
Action items
Owner Due Task
AI agent team (WS2) Sprint AI (post-ratification) Build /investors v2 (or /investors?v=2 parallel) with three-way "what's in it for..." tabs and RRP tables
AGENDA ITEM 12

Ratification artefact — FOUNDATION_MODEL_v1_2_PROPOSAL.md

Raised by: PMO
Discussion
Chair directed that no code be written against the session resolutions until Steerco ratifies. The session output takes the form of a single canonical reconciliation memo capturing all five model decisions, the comparison table vs Vol 5 v1.1, the financial model at three scale points, the sprint plan implications, and the three open questions for Steerco. The memo was produced and committed within the session under Sprint AB-tail discipline.
Resolution ACTIONED
docs/design/FOUNDATION_MODEL_v1_2_PROPOSAL.md produced, committed at ca7da3c, pushed to origin/main, deployed to production at 27414847.flip360.pages.dev. Full three-destination standing-order discipline discharged.
Action items
Owner Due Task
Chair 2026-07-06 (SC#3) Table FOUNDATION_MODEL_v1_2_PROPOSAL.md at SC#3 for formal ratification
AGENDA ITEM 13

PMO governance discipline — flying-minutes template

Raised by: Ms Oliver (Chair)
Discussion
Chair directed that this working session (and every future working session between the PMO Director and the AI agent team) must produce a flying-minutes record in the PMO-governance-grade format that a Big-4 engagement Director would recognise. The AI agent team confirmed the artefact class does not yet exist in the codebase (STEERCO_MEETINGS holds only the six formal Phase 1 Steercos; there is no artefact class for PMO-Director-to-agent-team working sessions). This file (src/routes/pmo-minutes.tsx) establishes the template. Every future material working session gets its own dated record at /engagement/pmo/minutes/:date.
Resolution RESOLVED
PMO working-session flying-minutes established as a first-class artefact class in the codebase, distinct from STEERCO_MEETINGS. Route pattern: /engagement/pmo/minutes/:date. Attribution discipline mandatory: every idea attributed to its originator (Chair, Mr Punter, AI agent team, or external contributor).

Open matters tabled at SC#3 (2026-07-06)

Sprint plan implications

Sprint sequence AC → AI is triggered by SC#3 ratification of this session's resolutions. All sprints additive-only, following the U → AB discipline that got Vol-2 MVP to production: • Sprint AC · Onboarding wizard (/onboard/*) — services, RRP-guided fee slider, community nomination, platform take disclosure, ABN/bank • Sprint AD · Foundation ledger extension — 4-leg accrual (net to earner / Foundation 14% / platform 1% / membership stream), 80/20 split at Foundation entity • Sprint AE · Referral consent capture (/consent/:token) — public consent flow with signed audit trail (EA Rule 4 discharge) • Sprint AF · CM territory model + /cm/* operator dashboard — territories, provider assignment, shortlist curation, quarterly reporting • Sprint AG · Community distribution mechanic — Foundation payouts to community orgs from Foundation-held account (blocked on Foundation incorporation + DGR + legal review) • Sprint AH · Public /community transparency page with per-territory breakdown — the marketing engine • Sprint AI · Investor brief v2.0 extension of /investors surface — three-way "what's in it for..." tabs + RRP tables + CM economics Estimated engineering: 6–9 sprints, 8–12 weeks of solo AI-augmented delivery under the Chair's (Ms Oliver) WS2 Lead accountability per D110. Non-engineering critical path items (PMO-owned, must resolve before or during the sprint sequence): • Territory Charter drafted before AF starts • Deed of Trust drafted before AD starts • Foundation entity incorporation + DGR registration before AG can distribute • Legal counsel review of democratic vote mechanism before AG • Legal counsel review of CM legal status before CM#1 recruitment • Curation of initial community org registry (~200–500 orgs across pilot territories) before AF launch

Sign-off block

Role Name Signed Date
Chair · PMO Director Ms Carla Oliver ☐ Pending —
Product Owner · Founder Mr Mathew Punter ☐ Pending —
WS1 Lead · Marketing & Digital Acquisition Ms Corrina Marven ☐ Pending —
PMO governance discipline
Prepared by Ms Carla Oliver, PMO Director, on 2026-07-04.
Attribution intact · hazards named · Mr Punter's originating contributions to the Community Manager territory model and the platform-earnings redistribution architecture recorded as his ideas. Design, build, and implementation of both remain the responsibility of the PMO Tech Workstream (WS2) per Steerco Decision D110.
Full three-destination standing-order discipline: sandbox commit · GitHub push · Cloudflare Pages deploy.
Matt's page