Status. Draft staging note for work package R1. It moves to
01-Overview/once the owner override is active. The Concept Note and Blueprint are marked v1.0 (20 October 2026); the Idea and the Concept and Architecture file carry no version marker. All four are client-supplied and GGA acceptance of them is not recorded. No scenario has been executed.
GGA requirement register
One row per requirement taken from the four client documents. Source codes: IDEA docs/high-level-idea.md; CN Concept Note; CA Concept and Architecture; BP pN Blueprint page N. See GGA-Source-Digest.
How to read the class column
| Class | Meaning | Treat as |
|---|---|---|
| Fixed commitment | One of the six commitments on Blueprint p. 1, or an explicit no-penalty promise | Core of the concept; still client-supplied, GGA acceptance not recorded |
| Proposed default | Labelled proposed in the Blueprint (intervals, limits, targets) | Configuration value for the pilot, not a promise and not a decision |
| Launch decision | One of the p. 20 settings and ownership decisions | Open until recorded by the named authority |
| Design proposal | Business rule or design in the Blueprint; p. 20 calls these specific design proposals | Requirement for the build, subject to the launch decisions |
| Deferred | Explicitly deferred until the model is proven | Out of the first release; guarded against scope creep |
| Concept statement | Intent or rationale | Context, not a testable rule |
Totals: 174 requirements. Design proposal 136; Proposed default 13; Launch decision 10; Fixed commitment 8; Concept statement 5; Deferred 2.
Where a requirement conflicts with the earlier vault (revision 1.3), the client document governs. Where the earlier vault says something the documents do not mention, it stays as Proposed with the label no GGA feedback received (see the supersession register).
Programme
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-001 | GGA is a business opportunity platform connecting companies in India, Japan and South Korea. | IDEA; CN p1; CA p1 | Concept statement |
| REQ-002 | One online session of one hour every two weeks: Japan and South Korea opportunities, founder insights, relevant partner presentations. | BP p1; CN p1; CA | Fixed commitment |
| REQ-003 | One major GGA event every six months bringing companies and country partners together. | BP p1; CN p1; CA | Fixed commitment |
| REQ-004 | Mandatory high-quality company data with recurring confirmation and enforceable freshness rules. | BP p1; CN p1 | Fixed commitment |
| REQ-005 | Public opportunity summaries, eligible-member details and permission-based private sharing. | BP p1; CN p1 | Fixed commitment |
| REQ-006 | Japan and South Korea partners independently source and maintain opportunities; each listing has a named owner, terms, next step and expiry. | BP p1; CA | Fixed commitment |
| REQ-007 | INR 5 lakh annual contribution after recognised value and explicit company opt-in; payment does not determine access. | BP p1; CN p1; CA; IDEA | Fixed commitment |
| REQ-008 | Anand provides convening and selected relationships; an operations owner handles routine decisions and exceptions. No one-to-one mentoring, unrestricted personal access or deal guarantee. | BP p1; CN p1; CA | Fixed commitment |
| REQ-009 | Core exchange: reliable company information in return for useful opportunities and connections. | IDEA; CN p1 | Concept statement |
| REQ-010 | Companies and partners own negotiation and delivery; GGA records progress and reported outcomes. | IDEA; CA | Concept statement |
| REQ-011 | AI may assist with summaries and matching, but people confirm business information and approve sensitive actions. | IDEA; BP p7 | Design proposal |
| REQ-012 | Start with 20 companies and validate the complete workflow before expanding towards 100 pilot companies. | IDEA; BP p1, p19 | Design proposal |
| REQ-013 | Intervals, limits, service targets and defaults labelled proposed are pilot recommendations and configuration values, not additional promises to members. | BP p1 | Concept statement |
| REQ-014 | Success is measured through useful introductions and company-reported value; routine work is owned by operations and automation. | BP p1 | Design proposal |
| REQ-015 | Opportunity categories: distribution, partnerships, market entry, products, services, technology, IP, talent, expertise, investment/funding and other approved categories; categories organise discovery only, the portal does not execute investments, hire candidates or transfer rights. | IDEA; CA; BP p5 | Design proposal |
Scope
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-016 | First release: registration, profiles, public and member views, partner intake, moderation, introductions, reminders, sessions, outcome records and contribution tracking. | BP p1 | Design proposal |
| REQ-017 | Defer: native mobile apps, general social feed, open direct messaging, automated deal negotiation, complex recommendation models, full accounting system. | BP p1 | Deferred |
| REQ-018 | Defer: automatic LinkedIn publishing, WhatsApp automation and AI matching until consent, operations and data quality work. | BP p1 | Deferred |
| REQ-019 | One responsive website with role-specific navigation; English default; Unicode storage and language preference for Japanese and Korean; reviewed translations later without data-model change; multilingual UI not required in first release. | BP p10 | Design proposal |
| REQ-020 | Use SQL filtering initially; add dedicated search or recommendation infrastructure only for a measured need. | BP p11 | Design proposal |
Access
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-021 | Public visitor: approved summaries and public session/event descriptions; no member details, contacts or private files. | BP p3; CA | Design proposal |
| REQ-022 | Registered company with incomplete data: own profile, missing-field guidance, public views; no detailed discovery, new interest submissions or new event registrations. | BP p3; CA | Design proposal |
| REQ-023 | Eligible company owner or invited colleague: member details, sessions, event registration, own interests and outcomes; edits own records only; private material needs a scoped grant. | BP p3 | Design proposal |
| REQ-024 | Company with overdue data: own profile, introduction history, outcomes and contribution records; detailed discovery and new introductions pause; previously released contacts cannot be recalled. | BP p3 | Design proposal |
| REQ-025 | Approved country partner: own listings and consented pitches responding to them; no full company directory, unrelated company data or unrestricted exports. | BP p3; CA | Design proposal |
| REQ-026 | GGA operations owner: review queues, listing decisions, profile exceptions, introductions, events; reason required for sensitive overrides and exports; actions audited. | BP p3 | Design proposal |
| REQ-027 | Finance role: opt-ins, billing details, invoices, payments, reconciliation; no capability documents or revenue figures unrelated to billing. | BP p3 | Design proposal |
| REQ-028 | Technical administrator: accounts, configuration, support, recovery; no routine browsing of business data; exceptional access logged. | BP p3 | Design proposal |
| REQ-029 | Anand as convener: programme dashboard, selected relationships, strategic exceptions; routine approval queues assigned to operations. | BP p3 | Design proposal |
| REQ-030 | Treat organisation membership, profile eligibility, listing visibility and specific sharing consent as separate checks. | BP p3 | Design proposal |
| REQ-031 | Eligible = verified contact + active company membership + all required profile fields + current company attestation + no administrative hold. Grace period counts as eligible. Contribution status is absent from the expression. | BP p3 | Design proposal |
| REQ-032 | Check access on the server for every request, export, file download and background action; scope every company-owned record to its company and every partner action to an owned or explicitly delegated opportunity. | BP p3; CA | Design proposal |
| REQ-033 | Automated checks establish completeness and consistency; they do not prove every business claim is true. Do not label a merely complete profile as verified. | CA; BP p4 | Design proposal |
| REQ-034 | Sensitive contacts and documents require the owner’s permission. | CN; CA | Concept statement |
Profile
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-035 | Identity fields: legal or trading name, country, website or alternative business evidence, industry, primary language; normalise website/domain and flag likely duplicates; company record private by default. | BP p4; CA | Design proposal |
| REQ-036 | Accountable contact: owner name, role, verified work email, preferred contact channel, decision-maker; one active owner required; personal contacts restricted. | BP p4; CA | Design proposal |
| REQ-037 | Business substance: products/services, description, team-size band, annual revenue band or amount with currency and financial year; revenue is compulsory but a band is allowed; restricted to the company and authorised GGA staff. | BP p4; CA | Design proposal |
| REQ-038 | Capability evidence: at least one relevant case study, reference, certification or equivalent link/file; record source and review status; distinguish supplied from GGA-checked evidence. | BP p4; CA | Design proposal |
| REQ-039 | Offer and need: what the company offers, target markets, what it seeks, desired partner type, sectors; structured tags plus concise text; at least one specific objective. | BP p4; CA | Design proposal |
| REQ-040 | Readiness: timing, available capacity, decision-maker, budget/investment band where relevant; reasoned not-applicable option for conditional fields, never a fabricated value. | BP p4; CA | Design proposal |
| REQ-041 | Permissions: terms/privacy acknowledgement, reminder settings, sharing preferences, owner attestation, notice versions and timestamps; marketing permission separate from operational notifications. | BP p4; CA | Design proposal |
| REQ-042 | Onboarding: verify email, create or join an organisation, save a draft, show required-field checklist, collect attestation, evaluate eligibility. | BP p4 | Design proposal |
| REQ-043 | An email domain match must never grant automatic access to an existing company; existing owners approve colleague invitations; disputed ownership goes to operations. | BP p4 | Design proposal |
| REQ-044 | Retain exactly one active attested profile version per company. | BP p13 | Design proposal |
| REQ-045 | Keep profile versions, confirming user, source and timestamps; editing business content creates a new version and needs confirmation before use; flag ownership changes, contradictory claims and suspicious evidence for review. | BP p4; CA | Design proposal |
| REQ-046 | One selected company context per session; data model supports invited colleagues without multiple companies sharing one record. | BP p4 | Proposed default |
| REQ-047 | A bot may extract or draft information but the company must confirm changes before publication or use in matching; GGA retains source, confirmation date and edit history. | CA; BP p4 | Design proposal |
| REQ-048 | Company revenue, private contacts and documents remain restricted unless the owner approves sharing. | CA; IDEA | Design proposal |
| REQ-049 | Show duplicate-company support without revealing existing members. | BP p10 | Design proposal |
Freshness
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-050 | Bot requests a short confirmation every 30 days; no-change confirmation is valid and resets the clock; next_due_at = 30 days after the latest attestation. | CA; BP p7 | Proposed default |
| REQ-051 | Grace period of 14 days after a missed due date; reminders on grace day 7 and day 13; detailed discovery and new introductions pause at due + 14 days. | CA; BP p7, p20 | Proposed default |
| REQ-052 | A complete, attested update restores eligibility immediately unless an independent review hold remains. | BP p7 | Design proposal |
| REQ-053 | The bot asks for changes after a relevant introduction or an opportunity update (CA). | CA | Design proposal |
| REQ-054 | Event-driven prompts after a relevant introduction or material company change; financial figures retain their reporting year until replaced. | CA; BP p7 | Design proposal |
| REQ-055 | Compute eligibility at request time so a failed scheduled job cannot leave overdue access open; log failed delivery and route to operations. | BP p7 | Design proposal |
| REQ-056 | Intervals are configurable launch settings; disputed identity or capability claims go to GGA review. | CA; BP p20 | Proposed default |
| REQ-057 | Payment status never overrides the freshness rule. | BP p7 | Design proposal |
Opportunity
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-058 | Every listing needs a responsible owner, clear requirements, a next step and an expiry date before publication. | IDEA; BP p5 | Design proposal |
| REQ-059 | Information layers: public summary (title, category, broad sector/country, anonymous requirement, deadline, approved teaser); member details; restricted material (counterparty identities, personal contacts, confidential terms, financials, documents); internal metadata. | BP p5; CA | Design proposal |
| REQ-060 | Member details contain requirements, eligibility, scope, expected collaboration, commercial basis, timing, next step and owner-approved context; visible only to eligible companies. | BP p5 | Design proposal |
| REQ-061 | Publish only reviewed fields; names appear in public only when explicitly approved; approved public projection is the only source for unauthenticated pages, search previews and public APIs. | BP p5, p12 | Design proposal |
| REQ-062 | Lifecycle: Draft; In review (operations approves, requests changes or rejects with reason); Published; Changes requested; Expired or paused; Closed or rejected. | BP p5 | Design proposal |
| REQ-063 | Owner can pause or close a published listing immediately; a material amendment to a live offer pauses the affected listing until re-approved. | BP p5 | Design proposal |
| REQ-064 | Expired or paused listings are hidden from active discovery; show a non-sensitive unavailable notice at the original URL; block new interests; expired listings return only after owner reconfirmation. | BP p5; CA | Design proposal |
| REQ-065 | Closed or rejected: retain restricted history for authorised participants and operations; reopening requires review and a new expiry. | BP p5 | Design proposal |
| REQ-066 | Operations decides which categories are enabled and what evidence each needs; submitter confirms authority to share; screen for misleading claims, confidential names in teasers, duplicates and prohibited material. | BP p5, p20 | Design proposal |
| REQ-067 | Approved version is stored separately from the editable draft; GGA review checks completeness, authority and obvious inconsistencies, not independent verification of every claim. | BP p2, p5 | Design proposal |
| REQ-068 | Listing submission: IDEA lets independent country partners and participating companies submit; BP p14 allows create and submit with partner approval or eligible company status. Submission does not publish it. Open question N9: BP p13 also says only an approved partner may publish through the review workflow. | IDEA; BP p13, p14 | Design proposal |
| REQ-069 | Partner intake: only an approved partner may publish through the review workflow; partner cannot self-approve, view another partner’s pipeline or edit another owner’s listing. | BP p13, p18 | Design proposal |
| REQ-070 | Public home and board with approved summary cards, filters by country and category, next sessions, shareable public URLs. | BP p10 | Design proposal |
Introduction
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-071 | Company pitches for a specific opportunity; opportunity owner decides whether to engage; both parties approve the contact package before release. | IDEA; BP p6 | Design proposal |
| REQ-072 | Interest requires a concise fit statement, proposed next step and the exact profile fields the applicant permits the owner to see; never attach the full profile automatically. | BP p6 | Design proposal |
| REQ-073 | Consent record binds each approval to introduction, recipient, fields/files, purpose, version and expiry; changing the package invalidates prior approvals. | BP p6, p13 | Design proposal |
| REQ-074 | Release in one transaction: both approvals current, both users authorised, opportunity active, applicant eligible; release once; queue one delivery per recipient; reciprocal contact package. | BP p6, p15 | Design proposal |
| REQ-075 | Decline, timeout or withdrawal closes without releasing contacts; withdrawal allowed before release; after release revoke future portal access where possible, previously shared information cannot be recalled. | BP p6, p15 | Design proposal |
| REQ-076 | Track introduced, discussion held, pilot, deal, no fit, no response; an introduction is not a completed deal. | BP p6 | Design proposal |
| REQ-077 | One open interest per company per opportunity; consent request valid 14 days; owner may close sooner; operations can remind but cannot consent for a participant. | BP p6, p20 | Proposed default |
| REQ-078 | Interest, introduction and consent states: one introduction per interest; consent and grant are separate records. | BP p12, p13 | Design proposal |
Matching
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-079 | First-release matching filters by country, sector, offer/need, partner type, timing and owner-defined mandatory criteria; show reasons for a suggested fit; a score is never a probability of success; match only eligible companies to published unexpired offers. | BP p7 | Design proposal |
| REQ-080 | Optional AI drafts summaries, translations or field suggestions from permitted data; suggestions stay separate until approved; AI must not alter eligibility, publish, share contacts, send unsolicited outreach or approve fees. | BP p7, p18 | Design proposal |
Contribution
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-081 | Contribution is a separate voluntary workflow; no introduction, claimed deal or outcome creates a payment obligation or automatic invoice. | BP p8; CA | Design proposal |
| REQ-082 | Record value: reporting company, related introduction or event, outcome type, date, narrative, optional evidence; partner-reported and company-confirmed outcomes kept distinct; only the company confirms its own value. | BP p2, p8 | Design proposal |
| REQ-083 | Only the company’s authorised owner can confirm value and accept the contribution; show amount, approved tax treatment, proposed period basis and terms version before consent. | BP p8 | Design proposal |
| REQ-084 | Opt-in creates a finance task; finance approves bill-to details and total before issuing an invoice; store invoice reference and copy. | BP p8 | Design proposal |
| REQ-085 | Finance verifies bank receipt or provider confirmation; one 12-calendar-month term activates from settlement date; exact dates shown in the account; no overlapping terms. | BP p8, p15 | Design proposal |
| REQ-086 | Renewal needs a fresh decision; never auto-charge or auto-extend a term; declining or deferring does not alter data-based eligibility. | BP p8 | Design proposal |
| REQ-087 | Renewal invitation proposed 30 days before term expiry; renewal invoices scheduled at or after the current term ends; unexpected early payments go to finance review. | BP p15, p16 | Proposed default |
| REQ-088 | Voids, refunds and corrections are finance actions with reasons; retain history; duplicate payment does not create a second term; partial, disputed or mismatched payment is a finance exception. | BP p8, p15 | Design proposal |
| REQ-089 | First release: manual invoicing and verified bank-payment reconciliation in the operations console; payment gateway optional (hosted collection, no card data stored); provider webhooks verify signature and transaction identity, with unique provider transaction IDs. | BP p8, p14 | Design proposal |
| REQ-090 | No retrospective fee, no automatic charge, no loss of access for choosing not to contribute. | CA; IDEA | Fixed commitment |
Sessions
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-091 | Create each fortnightly session occurrence with topic, host, guest, date, timezone, meeting link, capacity and status. | BP p9 | Design proposal |
| REQ-092 | Proposed session agenda: 35 minutes of context, 15 minutes of partner opportunities, 10 minutes of questions. | BP p9 | Proposed default |
| REQ-093 | Six-monthly event with venue, programme, registration, capacity, budget owner, delivery lead; production is an operational project; the portal supports discovery and registration. | BP p9 | Design proposal |
| REQ-094 | Registration needs an eligible company profile; attendance stored separately; no duplicate registrations; capacity enforced atomically; waitlist; cancellation promotes the next waitlisted registration. | BP p9, p15 | Design proposal |
| REQ-095 | Send a registration confirmation and calendar file; notify registered participants of cancellations and changes; send no reminders for cancelled occurrences. | BP p9 | Design proposal |
| REQ-096 | Proposed reminders 24 hours and 1 hour before an occurrence. | BP p9 | Proposed default |
| REQ-097 | Occurrence updates cancel obsolete jobs and issue a clear replacement notice; reminders are built from the current occurrence version. | BP p16 | Design proposal |
| REQ-098 | Recordings and speaker material published only with permission; short follow-up; recordings not a condition of participation. | BP p9 | Design proposal |
| REQ-099 | Existing registrations remain valid if a profile later becomes overdue; new registrations need refreshed data; administrative safety holds override with a clear reason. | BP p9 | Proposed default |
| REQ-100 | Event delivery lead owns venue, logistics, budget and execution; obtain a funded plan before commitments; decide guest access and separate event charges explicitly. | BP p9, p20 | Launch decision |
Outcomes
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-101 | Outcome follow-up prompts proposed 14 and 45 days after introduction; ask about progress, not assumed success; stop after closure or opt-out of optional research messages. | BP p16 | Proposed default |
| REQ-102 | Outcomes belong to the reporting company; an authorised owner confirms value before accepting a versioned contribution offer. | BP p14 | Design proposal |
Architecture
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-103 | Single versioned application with relational database and background worker: public site, member portal, operations console; central policy service for permissions and workflow state; business rules central, integrations replaceable. | BP p11 | Design proposal |
| REQ-104 | Persist a workflow change and its outgoing job in one transaction; worker retries delivery; saving a profile must not require an email or AI service to be available. | BP p11 | Design proposal |
| REQ-105 | PostgreSQL is a reference choice, not a mandatory vendor; separate development, staging, production; managed backups; private object storage; encrypted connections; secret management; error and queue monitoring. | BP p11 | Design proposal |
| REQ-106 | Optional AI adapter and other channels (WhatsApp, social publishing) are separate enabled adapters; their absence must not block the core journey. | BP p11, p16 | Design proposal |
| REQ-107 | Use mature authentication and email components selected by the developer; calendar files or existing meeting provider; default to email for the pilot. | BP p11, p16 | Design proposal |
Data
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-108 | Every company-owned row carries company_id; every opportunity has an accountable owner_user_id and, where applicable, partner_id; membership checked before using a company context. | BP p12 | Design proposal |
| REQ-109 | Store profile versions and attestations; derive eligibility from authoritative timestamps and review status; do not trust a browser-supplied eligibility flag. | BP p12 | Design proposal |
| REQ-110 | Constraints: one active interest per company and opportunity, one introduction per interest, one processed settlement per provider transaction or verified bank reference, unique occurrence/user registration, unique active membership per company/user. | BP p12, p13 | Design proposal |
| REQ-111 | Store public, member and restricted opportunity fields separately; record state changes, consent versions, invoice actions, access grants; optimistic version checks. | BP p12 | Design proposal |
| REQ-112 | Entities: users, memberships, companies, profile versions, partners, opportunities and versions, interests, introductions, consents, grants, events, occurrences, registrations, outcomes, contribution terms, invoices, payments, files, audit, outbox, notices, preferences, configuration versions. | BP p13 | Design proposal |
| REQ-113 | Money as integer minor units with explicit currency; timestamps UTC rendered in the user’s timezone; index company ownership, listing state/expiry, interest status, due jobs; never store raw secrets in audit logs. | BP p13 | Design proposal |
| REQ-114 | Owner transfer requires confirmation; invitation expiry enforced; partner needs agreement reference and scope. | BP p13, p14 | Design proposal |
API
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-115 | Versioned endpoints with one set of server-side rules for web, integrations and operations console; paths are a reference contract. | BP p14 | Design proposal |
| REQ-116 | Endpoint groups: public opportunities, companies and invites, company profile (expected_version), attestations, opportunity detail (member projection), opportunity create/submit, review decision, interests, interest decision and consents, event registrations, outcomes and opt-ins, finance invoices and settlements, file download. | BP p14 | Design proposal |
| REQ-117 | Return request ID, typed result and resource version; 401 unauthenticated, 403 prohibited, 404 where existence must stay private, 409 stale version or invalid state, 422 validation, 429 rate limit. | BP p15 | Design proposal |
| REQ-118 | Mutation retries carry an idempotency key scoped to actor and action; a changed payload with the same key fails. | BP p15 | Design proposal |
| REQ-119 | Supply an OpenAPI contract and examples for every endpoint, including correction, withdrawal, cancellation and administration actions. | BP p15 | Design proposal |
| REQ-120 | Public opportunity endpoint is paginated and filterable by country and category. | BP p14 | Design proposal |
| REQ-121 | Interest creation returns the existing result on a matching retry and enforces one open interest. | BP p14 | Design proposal |
| REQ-122 | Public listing API returns approved summaries only with no private field in HTML, JSON, metadata or cached responses; file download checks owner/grantee, version, scan state and grant expiry and never exposes storage keys. | BP p14 | Design proposal |
Transactions
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-123 | Profile attestation commits attestation, due date and audit together; an older draft cannot overwrite a newer confirmed profile. | BP p15 | Design proposal |
| REQ-124 | Owner accepts interest: one pending introduction, owner’s scoped consent recorded, applicant consent request queued, no contact released yet. Both consent: lock, re-check, release once with grants and notifications. | BP p15 | Design proposal |
| REQ-125 | Consent withdrawn before release cancels pending consent and release job in the same transaction; after release revoke future grants, retain accurate history. | BP p15 | Design proposal |
| REQ-126 | Commit the state change, audit entry and outgoing event together; external messages run afterwards. | BP p15 | Design proposal |
| REQ-127 | Version configuration, publication approvals and terms so an audit can reconstruct which rule applied; explicit business-rule failures; never fall back to unrestricted access or automatic approval. | BP p15 | Design proposal |
Jobs
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-128 | Profile reminder daily scan, dedupe by company, cycle and type; stop old-cycle jobs after fresh confirmation. | BP p16 | Design proposal |
| REQ-129 | Listing expiry check regularly; remove expired from active projections; APIs independently enforce expiry; notify owner; review before republishing a material change. | BP p16 | Design proposal |
| REQ-130 | Interest and consent follow-up: notify owner of new pitch, remind only while pending, expire unanswered consent, re-check recipient and scope before delivery. | BP p16 | Design proposal |
| REQ-131 | Contribution and renewal jobs create finance tasks only after valid opt-in; transactional email and calendar; retain provider IDs, delivery outcomes, bounce status. | BP p16 | Design proposal |
| REQ-132 | Outbox record with unique business key, attempt count, next retry, last error; retry transient failures after 1 min, 5 min, 30 min, 2 h then operations exception queue; do not retry permanent permission or validation errors. | BP p16 | Proposed default |
| REQ-133 | Provider idempotency where available; reconcile uncertain delivery before resending; database lock prevents concurrent claims but does not guarantee exactly-once delivery; messages non-sensitive. | BP p16 | Design proposal |
| REQ-134 | Operations console shows queue age, failures and a safe retry action; a failed notification never bypasses consent, reactivates a listing or marks a contribution paid. | BP p16 | Design proposal |
Screens
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-135 | Screens: public home and board, register and join company, profile workspace (autosave, checklist, evidence upload), member dashboard, opportunity detail with pitch form, my interests and introductions, sessions and events, value and contribution (never an access upgrade), partner workspace, operations and finance console (separate queues). | BP p10 | Design proposal |
| REQ-136 | Every restricted screen explains the next action in plain language. | BP p10 | Design proposal |
| REQ-137 | Interaction standards: empty, loading, validation, locked, expired, retry states; preserve drafts after errors; keyboard operation; labelled fields; readable contrast; mobile width; short links to the authenticated portal; no confidential profiles or documents in reminder email. | BP p10 | Design proposal |
Security
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-138 | Mature authentication; verify work contact; MFA for privileged staff; deny by default; test role and company boundaries. | BP p17 | Design proposal |
| REQ-139 | Least-privilege runtime database credentials; if row security is used, test with the real application role because owners and privileged roles bypass it; keep application checks too. | BP p17 | Design proposal |
| REQ-140 | Files: allowlist types and sizes, validate content, scan before release, private storage, access-controlled downloads, sanitise displayed text, block executables. | BP p17 | Design proposal |
| REQ-141 | Consent and data minimisation; correction, export and deletion-request workflows owned by GGA; retention by record type; expire temporary uploads and grants; handle deletion across files, indexes and restores. | BP p17 | Design proposal |
| REQ-142 | GGA approves privacy notice, hosting region, cross-border sharing arrangements and category rules. | BP p17 | Launch decision |
| REQ-143 | Secrets outside source control; separate technical and business privileges; log grants, exports, overrides and finance changes without tokens or unnecessary personal data. | BP p17 | Design proposal |
| REQ-144 | Recovery: daily backups, 24-hour recovery point, 8-hour restoration objective; encrypt backups, restrict access, demonstrate a restore before launch and monthly during pilot. | BP p17 | Proposed default |
| REQ-145 | Performance test: 100 companies, 1,000 listings, 25 concurrent users; 95% of core page/API responses under 2 seconds excluding external delivery; monitor errors, job age, storage, monthly cost. | BP p17 | Proposed default |
| REQ-146 | Release discipline: staging, reviewed migrations, rollback procedure, dependency checks; alert technical owner; member-impacting incidents routed to operations with a communication owner. | BP p17 | Design proposal |
| REQ-147 | Private response caching rules; invalidate approved projections when publication is withdrawn; do not expose gated data through analytics, logs, search indexes, exports or social previews; public copies cannot be guaranteed to disappear. | BP p17 | Design proposal |
Acceptance
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-148 | Blueprint acceptance test A1: Public and private views: visitor sees only approved summaries; API, source HTML, caches and file URLs reveal nothing gated. | BP p18 | Design proposal |
| REQ-149 | Blueprint acceptance test A2: Required profile: missing revenue period, capability evidence or accountable owner prevents eligibility; form states what to correct; drafts saved. | BP p18 | Design proposal |
| REQ-150 | Blueprint acceptance test A3: Freshness boundary: at due + 14 days access pauses even if the scheduled job failed; valid attestation restores access immediately unless a hold exists. | BP p18 | Design proposal |
| REQ-151 | Blueprint acceptance test A4: Publication control: partner cannot self-approve, see another partner’s pipeline or edit another’s listing; changed or expired offer cannot accept pitches. | BP p18 | Design proposal |
| REQ-152 | Blueprint acceptance test A5: Scoped sharing: owner sees only applicant-approved fields; no contact before both current approvals; withdrawal or package change invalidates pending consent. | BP p18 | Design proposal |
| REQ-153 | Blueprint acceptance test A6: Concurrency and retries: two simultaneous accepts create one introduction; replayed jobs create no second grant, invoice or term; failed notification leaves a recoverable task. | BP p18 | Design proposal |
| REQ-154 | Blueprint acceptance test A7: Payment independence: declining contribution keeps access; a paid company with overdue data is paused; a partner-reported deal cannot trigger an invoice. | BP p18 | Design proposal |
| REQ-155 | Blueprint acceptance test A8: Event behaviour: duplicate registration blocked; capacity not exceeded concurrently; cancellation, waitlist, timezone and changed-occurrence reminders work. | BP p18 | Design proposal |
| REQ-156 | Blueprint acceptance test A9: Tenant and role isolation: changing a company or file ID exposes nothing; finance cannot read capability files; non-finance cannot record settlement. | BP p18 | Design proposal |
| REQ-157 | Blueprint acceptance test A10: Files and AI: unscanned or disallowed files cannot be shared; AI drafts stay unpublished until confirmation; AI cannot grant access or decide contribution status. | BP p18 | Design proposal |
| REQ-158 | Blueprint acceptance test A11: Operations and recovery: operations resolve a review, failed message and expired consent without Anand; backup restored in staging; performance scenario measured. | BP p18 | Design proposal |
| REQ-159 | Blueprint acceptance test A12: Commercial end to end: value confirmed, opt-in, finance-approved invoice, settlement, one dated 12-month term; expiry neither auto-charges nor removes eligibility. | BP p18 | Design proposal |
| REQ-160 | Definition of ready to pilot: all tests pass, no unresolved access-control defect, named operations and technical owners trained, email and invoice flows demonstrated, backups and monitoring work, funded pilot budget and launch decisions recorded, owner can export essential business records in a documented format. Demonstrate with synthetic data before inviting the first 20 companies. | BP p18 | Design proposal |
Delivery
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-161 | Five stages: confirm and design; foundation and publishing; complete the service loop; pilot with 20 companies; expand towards 100, each with an exit condition. | BP p19 | Design proposal |
| REQ-162 | Developer obtains fixed scope, estimate and support arrangement after the launch decisions are recorded. | BP p19 | Design proposal |
| REQ-163 | Handover package: GGA-owned repository, build/deploy instructions, dependency inventory, accounts under GGA control; migrations, field dictionary, API contract, permission policies, sample data, automated acceptance tests; operations guide; monitoring, backup/restore evidence, incident contacts, rollback; configuration register; monthly recurring-cost estimate. | BP p19 | Design proposal |
| REQ-164 | Pilot metrics: current-profile rate, active owner-confirmed opportunities, accepted introductions, discussions held, company-confirmed value, cash collected, operating cost, Anand’s total time; record source and time window; registrations and pitches are not realised value. | BP p19 | Design proposal |
| REQ-165 | Anand’s fortnightly hosting is about 26 hours a year before preparation, partner work and events; track the full time requirement and fund operations from an explicit budget. | BP p19; CA | Design proposal |
| REQ-166 | Keep partner commitments and event spending within a funded budget; expand against cash collected; name an operations owner before launch. | CA; BP p20 | Design proposal |
Launch decision
| ID | Requirement | Source | Class |
|---|---|---|---|
| REQ-167 | Programme and operating owner: name one accountable operations owner and a backup; batch strategic questions for Anand; routine approvals must not depend on him (owner: GGA). | BP p20 | Launch decision |
| REQ-168 | Founder time and funding: agree total weekly time cap, event commitments, pilot spend limit and partner compensation (owner: Anand and GGA). | BP p20 | Launch decision |
| REQ-169 | Data freshness: 30-day confirmations, 14-day grace, due/day-7/day-13 reminders, configurable (owner: GGA operations). | BP p20 | Launch decision |
| REQ-170 | Consent and retention: 14-day pending-consent expiry; retention periods by data type, withdrawal path, deletion ownership (owner: GGA data owner). | BP p20 | Launch decision |
| REQ-171 | Contribution terms: INR 5 lakh annually after recognised value and opt-in; finance approves tax presentation, invoicing entity, settlement and refund handling (owner: GGA finance). | BP p20 | Launch decision |
| REQ-172 | Categories and partners: approve enabled categories, partner onboarding criteria, publication evidence, any separate partner commercial terms (owner: GGA operations). | BP p20 | Launch decision |
| REQ-173 | Technology and support: choose hosting, region, authentication, email, file scanning, database and backup providers; confirm actual cost and recovery support (owner: developer and GGA). | BP p20 | Launch decision |
| REQ-174 | Event production: assign delivery lead, approve each event’s budget, decide guest access and separate event charges (owner: event lead and GGA). | BP p20 | Launch decision |