An airline has 100 seats. They sell 120 tickets (overselling). Passengers pay wildly different prices for the same seat. But the cost in "booking currency" (miles, ticket tier) is the same for everyone on that flight.

For HQ Lite: Credits = seat availability (how hard is it to book Monday vs Wednesday). Dollar value per credit = host's bilateral contract with each tenant. These are architecturally independent. The product must not conflate them.

Previous sessions tied credits loosely to square footage. May 20 resolved this: credits are derived from the physical count of bookable assets on the floor plan (desks, meeting rooms, conference rooms), not from sq footage. Square footage is a host accounting metric. Credits are a booking capacity metric. These are connected but not the same thing.

If the host already has 20% margin baked into their $52.50/sq ft pricing, HQ Lite doubles that margin. And because income-method building valuations run at 5–6×, adding $240K in annual income adds $1.2M–$1.44M to the building's appraised value. That's the conversation that gets a CFO's attention.

Four persona columns: HQ Lite (Super Admin) • Host • Member Admin • Member (Guest). Tony renamed column A live: “We could call it super admin. We could call it platform admin. Actually, maybe it’s better to just say super admin.” Confirmed internal-only.

Two-level numbering, restarting per column — numbered sections, then numbered activities inside each. “I did break it down a little bit differently because now it’s kind of got like an area and then sub areas within it.”

Colour coding: black and untagged = built and testable today. Orange = carries a bracket tag: [NOT BUILT] [PARTIAL] [API ONLY] [NO UI] [UI STUB] [ORPHANED] [BLOCKED BY DESIGN] [CLI ONLY] [AUTOMATIC] [N/A].

Sheet 2 — E2E Journeys: seven journeys, 43 steps, each with an expected-blocker column. J1 host cold start to live listing • J2 host plans and sells space • J3 member admin onboards a team • J4 guest books, changes plan, cancels • J5 company block and claim • J6 limits and edge cases • J7 wind down.

Where it goes: Tony — “Each one of these becomes a much more expansive test case that now gets put into our repository that all the testing will be done with.” One row, one test case.

Rob’s argument: “If I’m a member admin and you tell me I have — are you going to tell me I have seats or are you going to tell me I have points? If you just tell me I have points, mentally you have to help me bridge that into what my job is, which is trying to get people in and sitting in seats.”

The consequence if it isn’t built: “The person that’s the member admin doesn’t care about points. They’re trying to get the right people in seats. And if they don’t have the clear visibility link between the points and the seats, they’re going to spin.”

Brandon’s spec: “Here’s your input of number of seats. The output of that is how many points you have left. And then we convert that and say, hey, here’s how many seats you have left based on this matrix.” Concretely: 20 seats Wednesday, 30 seats Friday — visible as a live readout.

Tony conceded the framing: points are “just an arbitrary thing for us to kind of give them access.” An internal abstraction, not a user-facing currency.

Requirement changed from “display the balance” to “display a live bidirectional conversion at every decision point.”

Hosts are invited, not self-serve. Existing self-signup is now considered wrong. Tony: “We’re middlemanning it right now… by manually creating the accounts and then operating those accounts.”

Cloud-only on AWS. On-prem and per-host isolated instances explicitly rejected — not on cost, but on the cross-host member case: “I’m in this location on Mondays and I go to this location on Thursdays.” One system manages it. Escape hatch reserved for a mega-customer with a hard security requirement.

Contract start date is driven by the signed agreement date, not invite acceptance. Reworded live.

Member Groups are V2 — but the need (bulk reserve for a recurring team) was decoupled from the mechanism. Rob: “maybe it’s not member group, just some other flag.” Robin and Envoy cited as prior art.

Per-guest points accrual rejected as too complex — a junior analyst coming two days a week needs a fractional, day-dependent allocation like 3.2 or 3.8 points. Member Admin allocates instead; the guest just books within an allowance.

Cancelled bookings stay visible for one specific reason: auditability of forfeited points. Tony went further — “we may actually want to build out a specific report to highlight that for member admins.”

Two-factor available by default for hosts, optional not mandatory. Matt: “that’s the kind of persona that thinks I’m entering in financial protected data… we should not be afraid of saying, yeah, two factor is here by default for hosts.”

A deliberate decluttering pass added to Matt’s work — “there’s a lot of leftover mess after all the work that’s been happening… which is actually what I think the UI needs right now, which is a decluttering.”

“We’re getting to a critical mass point with that. It’s code, it’s features. It’s going to be data. And so it’s a product that’s not a couple workflows that someone else could have automated on Excel or whatever. And so that’s where for me it’s a little bit of an ‘oh shit’ moment of, okay, if we really say this is this thing and we go and we put it out there… there’s going to be a hardening process of moving away from that vibe-coded term to, this is an enterprise production-level application.”

And the reason it matters: “It’s financial data, it’s financial implications to their business. If something goes wrong and we can’t answer why, they’re going to say goodbye.”

Compliance load, ranked: SOC 2 is the heavy one and long-term (“distinct requirements… that one actually will need some specific focus”). GDPR is framed as easier — data handling and right to be forgotten. PIPEDA for Canada. The US is assessed as least demanding. Mitigating argument is data minimisation: “we get their name and their email, but we’re not keeping anything crazy about them.”

Pre-launch legal artifacts now line items: terms and conditions, a legally approved privacy agreement, and the HQ Lite to host licence agreement.

Rob’s framing: “We’re sort of at that pinnacle where we have to decide, do we continue to try and refine, or do we start testing and then use the testing results to refine?” Answered: testing.

Tony’s status call: “I feel like we’re at the 85% point and this is where stuff starts to take longer.” All core critical problems identified over the last 12 weeks are resolved. “Now when I’m jumping into the interface it’s more finding the issues in the system rather than building out new functionality.”

Baseline scenario: one host, one member admin, one member user — full end to end. Expand to additional personas and edge cases from there.

Two-pass method: Tony writes the step-by-step guide first and circulates it (“does this feel like it captures what we’re doing?”), then the group walks the system against it. Explicitly not ad hoc — “the problem with doing it on the fly is you start to get lost… you get lost in what else is on the screen.”

The guide becomes the permanent regression baseline, and its acceptance criteria feed automated tests: “once we have those relatively captured that’s all automated, we just push those into user tests.”

The model (Brandon): “We think we’re able to allow you to recover $5 a square foot. We want to share in that upside. So we’ll charge you $2 a square foot. We’ll charge like 40% of the economic value.”

Why not per seat: “That’s definitely the industry moving away from that because people are shifting from labor to capital, and capital meaning AI. So you don’t want to be tied to that. You want to be tied to the actual economic value.” Brandon’s concrete case: if a contractor does the same job with 50 fewer administrative people, “we’re not getting docked for 50 less licenses.”

Tony’s independent confirmation from the product side: “Your asset in our system is the floor plan, and the floor plan is based on square footage. So I think it’s the simplest approach for right now.” He also noted the payer is the property owner, not the seat occupant.

Price anchor: $1–$2/sq ft, benchmarked against what landlords already pay for janitorial and paper shredding — it slots into an existing cost-of-goods line rather than creating a new budget category.

Self-auditing: square footage needs no customer audit — “because we see what they’re uploading into the system.” A material advantage over project-volume pricing, which requires auditing the customer’s books.

Notable: the AI model Tony ran beforehand recommended per-seat pricing. The group overruled it.

Steve, cutting off the incentive discussion: “Hang on a sec. You have to understand how the brokerage business works. We don’t have to worry about paying these guys. They will get paid. And we don’t have to worry about incenting these guys either, because they essentially get a percentage of the transaction… That is the incentive — that our model is essentially putting more space on the market. All of this dead and feral space that isn’t moving now becomes potential space.”

Why it self-sells: “They’ve got vacant space that they can’t move, that they’ve got the listing for, and it’s driving them nuts because they’ve got to invest all this time on this dead dog. This gives them an alternative to liven the dead dog… It’s self-selling to the brokerage community. What we need are people to go to the brokerage community and explain to them why this is a good thing. And they’ll get it like that.”

The junior-broker mechanism (answering Brandon’s worry that smaller deals hurt brokers): senior brokers hand 5,000 sq ft deals to juniors and participate in the income, exactly like articling. Higher deal volume is a feature, not a threat.

Steve’s closer for a landlord: “Why wouldn’t you just hire Cushman & Wakefield — their property managers as well? So this is a completely hands-off solution. And oh, by the way, you get to walk away with an extra 10 bucks in your pocket. What’s the downside?”

And for a national tenant: “You can actually bring all of your people in Toronto into the office four times a month without having to pay for all that square footage. And this model is applicable across North America. So how about you give me the assignment to help you right-size your portfolio across North America, and we’ll work with HQ Lite.”

Model: Members start at 200 points (one month’s worth) on day one of their term. Weekly replenishment tops the bucket up to the 200 cap — it does not add a flat 50 regardless of balance.

Example: 175 points on hand + weekly accrual = 200 (not 225). The cap is enforced at every replenishment.

Why weekly, not daily: Daily accrual creates weighted-valuation gaming opportunities. Weekly intervals are simple and predictable.

Why a cap at all: Motivates usage. Members who hoard lose the incentive of accrual — “use it or lose it” for recurring empty reservations. The cap is also the system’s memory limit — preventing runaway point accumulation across a long term.

Last month of term: No additional 200-point credit at end of term (points issued at start, not end). Renewal triggers a new agreement and fresh allocation. Bonus-point loyalty incentive floated as V2.

Block booking (Member Admin action): Reserves N seats for a date range. Consumes points at commitment time. Acts like a hotel conference block — the seats are held but specific desk assignments aren’t made yet. Admin sets the ceiling; individuals fill from within it.

Individual desk selection (End User action): Picking a specific desk within a pre-allocated block. This is NOT a booking. It should be freely adjustable up to a cutoff (approximately one week before the date). No points consumed at this stage — already paid by the block.

Release rule: Unselected seats in a block return to the general pool at the cutoff (approximately one week out). Partial credit may apply for released seats. No-shows on the day: no credit — the cost of the advance blocking privilege.

Why this distinction matters: Treating block commitment and desk selection as the same action creates bad UX and bad accounting. The two surfaces must be separate in the data model and the interface.

Batch enrollment: Adding a large team should support bulk import (e.g., 50 employees with three permission tier assignments in one operation).

Internal view (same company): Show names or employee identifiers on booked desks. Your own team sees who is sitting where.

External view (other company’s seats): Color-code by company (e.g., blue team vs. red team dots) but do not reveal individual names. Hovering to reveal a name from another company is a GDPR / privacy concern — anonymization must be enforced at the data layer, not just the UI layer.

Implementation: External companies appear as colored zones or anonymous markers. Internal employees see their colleagues’ names only. The host sees everything in host view for facilities management purposes.

Rather than manually scenario-planning every edge case, run competing AI agents against the booking system:

Persona 1 — Rule-following member: Books weekly accrual as intended. Baseline behavior. Shows what the system looks like when used correctly.

Persona 2 — Maximiser: Tries to extract the most value possible. Finds and exploits every loophole. Books speculatively. Cancels strategically. Surfaces the gaming scenarios the team hasn’t thought of yet.

Persona 3 — Host adjudicator: Watches both agents, resolves conflicts, generates recommended responses. The output is a draft FAQ of host guidance for common conflict scenarios — which the team can then review and formalize.

Goal: let AI enumerate the loopholes so V2 rules are grounded in real abuse patterns, not speculation.

At booking: Points are deducted from the member’s balance the moment they confirm a reservation. The seats are locked in. The balance reflects reality immediately.

Why: If points only deducted on the day of use, members would never know their true available balance when planning future bookings. The dashboard would be misleading. Points-at-booking makes the balance trustworthy.

Cancellations: Partial refund if cancelled 24+ hours before the booking date. Points forfeited if cancelled within 24 hours or not used. No-shows = points gone.

Effect on gaming: A member who books out the whole floor on Wednesday burns through their points immediately and can’t book anything else until the weekly replenishment. This is intentional — the rule creates natural scarcity without a hard cap.

Starting pool: Seats × 20 = starting balance. 10 seats → 200 points on day one.

Weekly replenishment: 50 pts added at end of each week (= one quarter of base, for a 10-seat member). Added to a maximum of the starting balance — never above it.

Example A (heavy user): Start 200 → use 100 → end week at 100 → +50 → 150.
Example B (light user): Start 200 → use 10 → end week at 190 → +10 (only enough to reach cap) → 200.

Key principle: You can’t accrue beyond your contracted maximum. The cap enforces the "use it or lose it" spirit without a complex rolling-day mechanism.

Open question (needs Steve): Monthly vs. weekly replenishment. Monthly is cleaner and avoids end-of-week booking rushes, but creates hard end-of-month spikes. Weekly was kept for now pending Steve’s input.

Anchor: Standard desk, Tuesday = 1 point.

Day modifiers: Monday 0.8× • Tuesday 1.0× (anchor) • Wednesday 1.3× • Thursday TBD • Friday TBD

Seat type modifier: Standard desk = 1.0× • Office seat = 1.5×

Conference rooms: Parked. Not tied to points in V1. Shared amenity policed by host; existing tools (Outlook, Robin) handle booking. Members get proportional access as if they own the whole office.

Result: A standard desk on Monday costs 0.8 pts. An office seat on Wednesday costs 1.95 pts. A member buys seats, not specific desks — the matrix shows them the range of outcomes depending on when they show up.

Window: 20 working days (not 28 calendar days).

Starting pool: Member begins with full pool = contracted seats × 20. (e.g., 10 seats → 200 points on day one.)

Replenishment: Weekly — one week's accrual is added, oldest week drops off. Not daily. Points never exceed contracted maximum.

Booking ahead: Members can book up to 20 days out. They can spend future points now — but if they don’t show, those points are gone.

Unused points: Lost when the window rolls. No banking beyond the cap. Use-it-or-lose-it by design.

Contract start/end: All contracts start and end on Monday/Friday. This keeps the rolling window clean and removes calendar-month complexity. If a member starts mid-week, host can manually accommodate as a one-off freebie.

Dimension 1 — Day of week:
• Monday: ~0.9× (cheaper; drive off-peak usage)
• Tuesday: 1.0× (anchor — reference point for all pricing)
• Wednesday: ~1.2× (peak demand)
• Thursday: ~1.0×
• Friday: ~0.9× (cheaper; drive off-peak usage)
Zero-sum: Mon+Tue+Wed+Thu+Fri = 5.0 — high-demand days cost more, low-demand days cost less, net equal

Dimension 2 — Seat type:
• Hot desk / standard seat: 1.0× (base)
• Private office: ~1.5× (stacked on top of day multiplier)
• Conference rooms: parked for V1 — no point cost; host-policed separately

Example: Wednesday private office = 1.2 (day) × 1.5 (office) = 1.8 pts. Monday hot desk = 0.9 pts.

AI-validated fail-safe (Gemini): Optimised formula — day weights 0.6/1.2/1.4/1.2/0.6; point costs 15/30/35/30/15 = 125 total weekly. 125 > 120 points in circulation. The space can never be 100% simultaneously overbooked — the math prevents it.

Level 0 — Host: Full visibility across all tenants. Sets booking rules. Adjudicates conflicts. The “facilities manager” of the shared office.

Level 1 — Tenant Super Admin: Controls the entire member account. Allocates points and seat budgets down to Admins.

Level 2 — Admin (team/department lead): Manages a subset of seats from the Super Admin. Can book on behalf of team. Sees team-level utilization only.

Level 3 — Individual User: Books their own desk. No visibility into contract terms. Must be the easiest layer — one click to see available seats, one to book, one to confirm.

“Simplexity”: the simpler the UX at the bottom, the more complex the back end. That complexity is where the platform creates value — the user sees nothing except a floor plan and a confirm button. This is the Uber model.

Old flow: (1) Invite member → member accepts → (2) Create contract separately — two screens, near-duplicate data, confusing ordering.

New flow: Host negotiates terms offline (email, broker, LOI). Once agreed, host goes to step 4 in the system: upload the signed contract PDF + fill in the operating details in one combined screen. Clicking "invite" at the end sends the member a single email: here is your access + a copy of the signed contract.

What the combined screen captures:
• Company info: name, address, phone, primary point of contact, email
• Agreement terms: license start date, license end date, monthly fee ($), % capacity share (which derives bookable seat allocation), included services
• Upload: signed contract PDF

What stays in the PDF only (not extracted): guarantor, insurance, indemnification, termination clauses, legal boilerplate.

Amendment workflow: Contract terms are locked after activation. Changes require a formal amendment process (separate workflow, not just editing the screen) — sends notifications to the member.

Host side ends at: The contract screen (upload PDF + fill operating details + click "invite"). This page is locked from the member side — the member cannot edit any of it.

Member side starts at: A read-only summary of the same contract details. The member sees: what they signed, what their allocation is, what their included services are, and when their license runs.

Member then fills in their half: Operational contacts (who to call, billing address, who's on site), payment/invoice routing details, sub-user invites. This is the member's "master file" — editable by them, not by the host.

Sync: When member updates their operational details (new contact, billing address change), the host sees an updated read-only view. Host cannot edit it; member cannot edit the contract half. Two separate locked halves of the same record.

Column order: Bookable Seats (input) | % Share (calculated: seats ÷ total bookable capacity) | Monthly Rate (input: $ charged to this member) | Rate per Seat (calculated: monthly rate ÷ bookable seats)

Capacity cap: Cumulative bookable seats across all members cannot exceed total bookable capacity (physical seats × multiplier). The table blocks entry once you hit the cap.

Totals row: Sum of bookable seats, weighted-average rate per seat, total monthly rate. Plus an Unallocated Balance row showing remaining bookable capacity still available to sell.

What's removed: Daily points column, capacity multiplier display, square footage column. Points belong in a separate admin section when configuring the actual points allocation — not here.

What's retained from prior sessions: The 1.2× multiplier applies under the hood to calculate total bookable capacity. The planning tab just shows the result (e.g., 162 bookable seats) without exposing the formula.

A sublease transfers occupancy rights — the subtenant gets defined square footage, their own lease term, and participates in guarantees. A license grants access to use a space without transferring any rights of tenancy.

HQ Lite members are licensees. The primary tenant (e.g., Acme Financial) retains all lease obligations and guarantees. The member gets access, not occupancy rights. "Like renting a car — you can drive it, but you can't take it in for new tires."

Pool: Contracted seats × 20 working days = starting balance. Example: 10 seats → 200 points on day one.

Replenishment: Weekly top-up to the 200 ceiling. You receive however many points are needed to reach 200 — not a flat +50. If balance is 190, you get +10. If balance is 50, you get +50. Never above 200. Like a capped PTO accrual.

Points-at-booking: Points deduct immediately when a booking is confirmed. Balance reflects reality at all times. No deduction on day-of-use.

Rolling window: 20 working days (4 weeks). Members can book any date within the forward 4-week window using their full available balance.

Spending: Variable — day multiplier × seat type multiplier. Standard desk, Tuesday = 1 pt. Office seat, Wednesday = 1.2 × 1.5 = 1.8 pts. Zero-sum design: weekly point costs sum to 5 — AI-validated fail-safe (125 total weekly cost > 120 pts in circulation) makes full simultaneous overbooking mathematically impossible.

Daily cap: No hard cap in V1. Host adjudicates booking conflicts. “Use it or lose it” for recurring empty reservations.

Contract constraints: All contracts start and end on Monday/Friday. No 200-point credit issued in the last month of term; renewal = fresh allocation.