Status. Owner conversation notes, 2026-10-28. Proposed direction only: not a DG decision, not an accepted design and not implemented. No Qnn/Dnn is answered by this note.
Lead tracking: owner feedback (2026-10-28)
What the owner said
- Tracking log, not messaging. No messages and no WhatsApp or chat integration. Each lead holds a short log of what has been done and where it stands now, like order tracking for a parcel. Nothing in depth.
- The operator writes the log. The person working the lead (GGA staff, currently the owner) updates it after calls, trips and meetings. Clients need not be on those calls; voice notes and similar stay off-platform and are summarised by the operator. Documents and notes may be attached as inputs.
- One thread per lead. Example: a Fukuoka trip is one thread and all its inputs stay inside it; a rice-company connection is a separate thread.
- One request = one project. “Wants to become a co-founder” and “needs a co-founder” are separate projects. Ten posts asking for a co-founder are ten projects; one person connected to ten people is also ten projects. Parties do not see each other’s connections.
- Mandate locks a lead one-to-one. Before a mandate, a lead (e.g. Fukuoka) is open to everyone. Once mandated, only the mandated party can see and act on it; everyone else sees a disabled, non-clickable entry labelled e.g. “Fukuoka mandate”. The mandated party is asked to focus on that lead only, so it closes cleanly and nothing is forgotten.
- Per-login view. Each user sees only their own threads and their updates.
- Simple, one-person operable. Easy for GGA and for clients; one person must be able to run the platform. The owner flagged data-race concerns (e.g. two parties acting as a lead becomes mandated).
- Journey before development. Confirm the user journey first, drawn by hand on paper for clarity (neat handwriting not needed). Digitise and build only after the owner confirms it. Less prompt-and-revise churn.
Conflicts with the current proposed design (recorded, not resolved)
| Owner feedback | Vault rev 1.3 / prototypes | Note |
|---|---|---|
| No messages; operator status log | Engagement-and-Tracking owns conversations, messages, discussions | Messaging may shrink to an operator-written update log. Needs owner confirmation before any vault/ADR change. |
| Mandate hides a lead from others | Audience filtering exists; no “mandate” state | New lifecycle state + visibility rule. Must still filter before search, counts and pagination; disabled entry must not leak private detail beyond its label. |
| One project per request/connection | Expression of interest per respondent per opportunity | Mapping of “project/thread” to opportunity/EOI is undecided. |
| Parties never see each other’s connections | Consistent with deny-by-default | No conflict. |
Engineering implications to carry forward (proposed): mandate assignment must be a single transactional state change with a DB constraint (at most one active mandate per lead) and an idempotency key, which addresses the owner’s data-race concern. Status updates append-only. No change to Q04, Q05, Q10 status.
Next action
Owner side: hand-drawn user journey covering lead creation → open lead → updates log → mandate → closure, plus the co-founder offer/need split. After owner confirmation: digitise, then decide which vault/module notes change. No prototype, issue or PR until then.