Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.

System components

Sources: Blueprint pp. 11 to 12, 16 to 17 (see GGA-Requirement-Register); retained findings from the 1.3 architecture (“modular monolith”, outbox, ports). Related: API-and-Request-Pipeline, Deployment-and-Operations, Data-Model.

One application, one relational database, one background worker. One versioned codebase serves three surfaces: the public site (approved summaries only), the member portal (profiles, offers, outcomes) and the operations console (review and exceptions). A central policy service decides permissions and workflow state; business rules live in one place and integrations are replaceable (Blueprint p. 11).

flowchart LR
  PUB[Public site<br/>approved summaries] --> APP
  MEM[Member portal<br/>profiles, offers, outcomes] --> APP
  OPS[Operations and finance console<br/>review, exceptions] --> APP
  APP[Application and API<br/>authentication, policy service, workflow rules] --> DB[(Relational database<br/>authoritative records, outbox, audit)]
  APP --> FILES[(Private object storage<br/>evidence, attachments)]
  DB --> W[Jobs and worker<br/>reminders, expiry, delivery]
  W --> EXT[External services<br/>email, calendar or meeting, accounting]
  APP -.optional.-> AI[AI adapter<br/>drafts need approval]
  DB --> BK[Backups and audit<br/>restore, change history]

Solid arrows are primary dependencies; the dashed arrow is optional. Every browser request reaches the policy checks before private data or files are returned.

Module	Responsibility	Blueprint
Identity and company	Verified users, companies, memberships, owner-approved colleague invitations, one selected company context per session	pp. 3, 4
Profile and eligibility	Structured profile, versions, attestation, evidence, freshness clock, eligibility computed at request time, administrative holds	pp. 4, 7
Partners and opportunities	Partner approval, listing intake, public/member/restricted layers, operations review, lifecycle, expiry, approved public projection	pp. 5, 13
Introductions and consent	Pitch, owner decision, scoped consent, one-time contact release, grants	pp. 6, 15
Events and sessions	Fortnightly occurrences, six-monthly event, registration, capacity, waitlist, reminders	p. 9
Outcomes and contribution	Reported outcomes, voluntary opt-in, finance approval, invoice, settlement, 12-month term	pp. 8, 15
Operations and notifications	Review queues, exception queues, outbox worker, retry, audit	pp. 10, 16
Files	Evidence and attachments: type and size allowlist, content check, scan, executable block, private storage, grant-checked download	pp. 13, 17

Publication contract (Blueprint pp. 5, 13): a listing needs a responsible owner, clear requirements, a next step and an expiry before publication; the submitter confirms authority to share; operations screens for misleading claims, confidential names in teasers, duplicates and prohibited material; operations enables categories and decides the evidence each needs. Partners and eligible companies can both submit (open question N9; see GGA-Source-Digest).

Security boundaries (Blueprint p. 17): runtime database credentials are least-privilege; if row security is used it is tested with the actual application role, because table owners and privileged roles bypass it, and application checks stay in place. Uploaded files: allowlisted types and sizes, content validation, scan before release, private storage, access-controlled downloads, sanitised displayed text, executable uploads blocked.

Boundaries: PostgreSQL is a reference choice, not a mandatory vendor. The application must not require an email provider or AI service to be up to save a profile. Use SQL filtering first; add dedicated search or recommendation infrastructure only for a measured need. Provider credentials stay server-side.

Retained from revision 1.3 (supports the Blueprint)

• Modular monolith with internal module boundaries; no separate business microservices needed.
• Transactional outbox and a worker from the same codebase.
• Vendor-neutral ports; provider credentials never reach the browser; provider and region choices belong to GGA (Blueprint p. 20).

Superseded from revision 1.3

• Four-module split (identity, opportunities, engagement, notifications and administration): replaced by the eight modules above.
• “Small DG membership approval and revocation tool”: replaced by the eligibility engine and operations holds.
• Private discussion module: no GGA feedback received; kept only as a Proposed carry-forward (see Step-06-Questions-Interest-Discussions-Actions), outside the first-release scope the Blueprint defines (open direct messaging is deferred, p. 1).