Women AI Network
A privacy-first community product that turns consent, purpose, and audience into enforceable system contracts.
I defined the product constraints, system architecture, implementation plan, review criteria, verification strategy, and public evidence boundary for this portfolio snapshot.
- Role
- Independent product owner and engineer
- Capability proof
- Shows privacy-first product judgment translated into consent graphs, purpose-bound data contracts, fail-closed serializers, minimized background payloads, and release runbooks.
- Technology
- TypeScript · Next.js · Node.js · PostgreSQL · BullMQ
Context
Women AI Network explores a multilingual community product for discovery, consent-based connections, circles, letters, messaging, and optional AI-assisted onboarding. The portfolio question was not simply how to build those features. It was how to prevent a growing product surface from weakening the member’s control over private facts, relationship choices, provider use, and communication.
The public repository is a portfolio snapshot. It uses synthetic fixtures and documents local verification and production-launch requirements. It does not claim real members, current community operation, customers, or revenue.
Problem
Privacy cannot be enforced by a profile switch alone. A member fact may be suitable for one purpose but not another audience. Consent may be withdrawn after a task is queued. A background job can preserve private content longer than the request that created it. A nested error can move a message body into logs. An AI proposal can appear authoritative unless the product keeps it separate from confirmation.
The system therefore needs a closed path from member intent to persistence and delivery: explicit consent transitions, current-policy checks at consequential boundaries, purpose-bound data shapes, minimal queue payloads, safe notification parameters, fail-closed serializers, and recursive diagnostic redaction.
Public evidence boundary
The repository includes an approved design concept that communicates product direction. It is not presented here as a screenshot of a live community or as proof of production behavior. This case intentionally publishes no fabricated runtime image. Engineering claims are instead tied to public architecture decisions, implementation contracts, verification instructions, and launch runbooks.
All examples and fixtures are synthetic. A real launch would still need managed infrastructure, configured providers, security and legal review, moderation and safety operations, monitoring, and named incident ownership.
Constraints
Constraints that shape the system
- Member facts, relationship preferences, private messages, and provider inputs have different purposes and audiences, so a single profile-visibility flag cannot govern them safely.
- Consent or account state can change after work is queued; final writes and external handoffs must re-evaluate current policy rather than trust clients, caches, or stale jobs.
- Queues, notification providers, logs, and diagnostics expand the data surface, so each boundary must carry only the minimum information required for its purpose.
- The repository is a portfolio snapshot with synthetic fixtures and a design concept, not evidence of real members, current production operation, or a live community interface.
Key decisions
Choices, alternatives, and trade-offs
Model consent as a policy-checked graph
- Context
- A UI checkbox cannot express relationship direction, blocks, eligibility, resource state, or a consent withdrawal that occurs after a request begins.
- Choice
- Represent relationship transitions explicitly and evaluate account, block, eligibility, and resource policy again at API and persistence boundaries before consequential writes.
- Alternatives
- Trust the client-selected visibility state; Authorize once and carry the result through queues or caches
- Trade-off
- Fresh checks add policy and transaction complexity, but stale work cannot silently preserve authority that no longer exists.
Separate facts, matching use, and member audience
- Context
- One profile value may be valid for a bounded internal purpose while remaining inappropriate for discovery, publication, or another member.
- Choice
- Store purpose and audience as distinct contracts, encrypt sensitive or AI-only values, and publish only confirmed low-sensitivity snapshots through fail-closed serializers.
- Alternatives
- Store one JSON profile with per-field conventions; Filter private fields only in presentation components
- Trade-off
- The schema and migrations are more deliberate, but new endpoints inherit explicit privacy boundaries instead of reconstructing them from convention.
Queue opaque intents, not private content
- Context
- Background payloads persist, retry, and appear in operational tools; copying member content into them would widen exposure and weaken revocation.
- Choice
- Let PostgreSQL own private notification state, carry only an opaque intent identifier through BullMQ, recheck policy before delivery, and build a generic localized-safe provider preview.
- Alternatives
- Render complete notifications before enqueueing; Place message or profile bodies directly in job payloads
- Trade-off
- Workers perform an additional state read, gaining current-policy enforcement, smaller payloads, and a clearer audit boundary.
Separate design concept from runtime evidence
- Context
- A polished concept can imply a live product, real members, or a verified production interface when none of those claims are supported.
- Choice
- Label the repository visual as an approved design concept, publish no fabricated runtime screenshot, and use code, ADRs, tests, and runbooks as the engineering evidence.
- Alternatives
- Present the concept as a product screenshot; Populate promotional screens with implied real member activity
- Trade-off
- The case is less visually theatrical, but the reader can distinguish product direction from implemented and verified behavior.
Architecture and failure behavior
Responsibility, input, output, and failure
- 01
Manual-first onboarding
Collect editable choices and explicit confirmation while keeping optional AI output as a short-lived proposal.
- Input
- Authenticated account, selected modes, answers, and consent receipts
- Output
- Confirmed, purpose-bound preference state
- Failure
- Manual onboarding remains usable when a provider is unavailable or consent is withdrawn.
- 02
Synchronous policy gate
Evaluate account, consent, relationship, eligibility, block, and resource state at the consequential boundary.
- Input
- Current server state and requested operation
- Output
- Allowed transition or deliberately limited rejection
- Failure
- Denies by default and does not disclose policy, age, membership, or block direction through errors.
- 03
Purpose-bound persistence
Separate facts, matching projections, audiences, encrypted values, and immutable published snapshots.
- Input
- Validated member intent and policy-approved changes
- Output
- Encrypted private state and bounded public projections
- Failure
- Strict repository and serializer contracts reject unknown or disallowed fields.
- 04
Consent-bound interaction
Manage circles, letters, and messaging only through accepted relationship and safety boundaries.
- Input
- Authorized relationship edge and member action
- Output
- Private interaction state or safety transition
- Failure
- Blocking invalidates accepted edges; unblocking does not restore access without new explicit consent.
- 05
Privacy-safe outbox
Persist closed event keys and safe parameters while queues carry only provider-intent identifiers.
- Input
- Policy-approved notification intent
- Output
- Generic localized-safe provider preview
- Failure
- Disabled providers remain pending or fail explicitly; they are never reported as sent.
- 06
Redacted operations boundary
Provide verification, lifecycle controls, and diagnostic context without private content.
- Input
- Runtime state, nested errors, and verification commands
- Output
- Redacted logs, bounded health, and release evidence
- Failure
- Recursive key-family redaction removes credentials, identity data, private content, prompts, and precise location.
Failure modes
How failure is detected, bounded, and escalated
| Trigger | Detection and response | Side effects and human boundary | Assurance |
|---|---|---|---|
| Consent is withdrawn or the account is disabled after work is queued. | The worker reloads current state and the final policy gate rejects the operation. Stop before the final write or provider handoff. | The queue contains only an opaque reference, not a reusable private payload. An already-started external call is recorded honestly rather than represented as cancellable. | Designed |
| A new endpoint attempts to serialize an AI-only or private profile fact. | Closed response schemas and member serializers do not recognize the field. Fail closed instead of returning a partial private record. | No disallowed value enters the member-facing response. A reviewed schema and policy change is required to expand an audience. | Designed |
| Nested provider or application errors contain sensitive keys. | Recursive redaction tests use nested canary values. Replace sensitive values before diagnostic output is emitted. | Credentials, contact data, documents, message bodies, prompts, and precise locations are excluded from logs. Unknown key families require a reviewed redaction-contract update. | Verified |
| A provider is unavailable or AI-provider consent is absent. | The adapter or consent gate fails closed. Keep the manual onboarding and editing path usable. | No provider payload is built without purpose and retention consent. The member can continue manually; no forced disclosure is required. | Designed |
| A release is mistaken for a current production community. | The README, case, disclosure, and launch runbook identify portfolio and production boundaries. Label synthetic fixtures and design concepts; withhold a live-service claim. | No real member data is used for public demonstration. Production requires infrastructure, provider, security, legal, and operational review. | Verified |
Project evidence
Evidence and its verification scope
Architecture
Sensitive operations are policy-checked beyond the UI, with minimized background payloads and redacted operational logs.
Portfolio implementation; not a live community service.Women AI Network README — system highlightsThe product idea is translated into explicit data contracts, policy gates, services, and migrations.
Repository-level architecture evidence.Women AI Network README — ownership and architectureRunbook
The repository documents setup, verification, and release controls instead of treating deployment as an implicit step.
Runbook evidence; not a claim of current production operation.Women AI Network README — local verificationHonest status
Implemented, not claimed, and still required
- Running status
- Portfolio snapshot
- Data
- Public demonstrations use synthetic fixtures only; the portfolio does not claim real member data.
- External integrations
- Provider adapters and infrastructure boundaries are implemented or documented for local verification; real external services require credentials and launch review.
- Revenue claim
- The case does not claim customers, community activity, production usage, or revenue.
- Source
- Public source
- Before production
- A real launch still requires managed infrastructure, a domain, configured providers, security and legal review, moderation and safety operations, monitoring, and incident ownership.
Portfolio snapshot: The repository demonstrates product architecture and engineering implementation; it does not claim that the service currently operates in production.
Reflection and next priorities
What worked
Making privacy a contract across policy, persistence, serialization, queues, and logs produced more reviewable decisions than adding visibility checks feature by feature.
What I would change
I would introduce the public evidence taxonomy—implemented behavior, verified local behavior, design concept, and production requirement—at the first product brief rather than at portfolio packaging time.
Next priorities
- Expand adversarial tests for consent withdrawal during provider handoff.
- Preserve dated verification artifacts for the highest-risk privacy contracts.
- Complete launch governance only if a real operating owner and moderation model exist.
Not worth doing yet: Growth mechanics and additional social features are lower value than proving consent, safety, and operational ownership under failure.