TECH STACK ASSUMPTIONS
.NET 10 (ASP.NET Core)
SQL Server (single shared database)
EF Core for persistence
Background processing via .NET Worker Service (written in C#)
OIDC authentication (generic provider)
Observability via structured logging + correlation IDs (OpenTelemetry-friendly)()
Hosting in Azure
APPLICATIONS / DEPLOYABLES (MVP TOPOLOGY)
There are multiple applications, all (except Public) using a single shared SQL Server database:

Public Site
Purpose: user frontend
Decoupled from product authentication and the product database.
Access to necessary common data through API only
Not part of the .NET architecture output (only link-outs and content assumptions).
more
User Web App (.NET 10 SPA)
Purpose: enable user to configure and manage. Examples:
beneficiary profiles
gift schedules
messages/media
funding setup and transparent pricing/buffer logic
plan settings (including fallback thresholds)
registry?
more
Role: User
Super User / Login As User?
Beneficiary Web App (.NET 10 SPA)
Purpose: provide a sensitive, minimal-friction portal for beneficiaries to. Examples:
view relevant gifts/messages/history
update contact details
opt-out
manage delivery preferences (where appropriate)
upload photos/videos/thanks (socials optional for MVP)
optionally share externally (social sharing is external; no internal community hub)
more
Role: Beneficiary
Super User / Login As User?
Admin / Ops Web App (.NET 10)
Purpose: manage operations across the platform. Examples:
global search (user/beneficiary/delivery events)
exception handling queues (bounces, vendor failures, cost spikes, manual review)
death verification workflow and schedule activation controls
vendor order visibility and manual retry/override controls
payout/refund/fallback execution tools (role-gated)
audit viewer and reporting
catalog/vendor configuration (optional in MVP; can be internal config tables)
more
Roles: Support, Ops, Admin
Automation Worker (.NET 10 Worker Service)
Purpose: background tasks:
scheduling execution and rolling-window “delivery due” generation
delivery event orchestration and retries
messaging campaigns (annual contact refresh, reminders)
webhook ingestion
Ability to deploy individually to Azure services
SHARED DATABASE STRATEGY (SINGLE SQL SERVER DB)
One canonical SQL Server database as the system of record.
All apps connect to the same DB directly (except Public site), but MUST follow strict governance to prevent drift:
Canonical domain tables and invariants are owned by “Platform” modules
Role apps (User/Beneficiary/Admin) should not implement conflicting business rules.
Enforce data access boundaries at the application layer (and optionally via DB views).
Prefer schema-per-module for clarity (recommended):
beneficiary.*
scheduling.*
funding.*
fulfillment.*
messaging.*
admin.*
ai.*
platform.* (cross-cutting system)
SECURITY / COMPLIANCE / RESILIENCE
Security goals
Protect PII and sensitive relationship data (beneficiary identities, contact info, messages) with least-privilege access and strong auditability.
Ensure trust-critical operations (funding, scheduling activation, delivery, payouts/refunds) are deterministic, role-gated, and fully traceable.
Design for long-lived reliability: the system must tolerate partial failures (vendor/API outages, email/SMS bounces, transient DB issues) without losing or duplicating data or actions.
Authentication & authorization
OIDC for interactive user authentication across User, Beneficiary, and Admin apps
Policy-based authorization with roles: User, Beneficiary, Support, Ops, Admin
Admin/Ops actions that mutate trust-critical state
PII data classification & minimization
Classify data into tiers:
PII: names, emails, phone numbers, addresses, identity-linking tokens
Sensitive content: personal messages/media, relationship context
Operational: delivery events, vendor references, audit metadata
Public site
Collect only what is required for fulfillment and contact maintenance
Prefer storing references/handles to external systems where possible rather than duplicating full sensitive payloads
PII protection (at rest / in transit)
TLS everywhere in transit
Encryption at rest for SQL Server storage and backups (platform default).
Separate storage/handling paths for any uploaded media; store only metadata + secure URLs in SQL (no blobs in DB unless explicitly chosen).
Data access boundaries (shared DB)
Enforce role-based row filtering in application query paths (User sees only their beneficiaries; Beneficiary sees only their linked records; Support/Ops constrained by policy).
Optionally provide read views per app to reduce accidental over-fetching of PII
Retention, deletion, and legal hold
Define retention policies by data class:
operational and financial records: retained per policy/legal requirements
PII and message content: retained only as long as needed for service and audit obligations
Implement soft-delete patterns where needed; ensure deletions are auditable
Operational security
Secrets/config managed via Azure mechanisms (managed identity + Key Vault).
Enforce least-privilege DB access per app identity.
ARCHITECTURAL STANCE
Optimize for MVP delivery speed while preserving a clean path to scale - heirloom gifts
Use “modular monolith” patterns:
AI assistance in non-deterministic functionality:
drafting/suggestions/insights
never moves money, never verifies death, never makes final delivery decisions, but is informing and advising on those decision
EXTERNAL API INTEGRATIONS (DELIVERY / PAYMENTS / MESSAGING / OTHER)
Integration philosophy
External systems are treated as unreliable and eventually inconsistent
All third-party interactions must be:
idenpodent
observable
auditable
expect failure
Integration architecture
All outbound integrations are executed asynchronously via the Automation Worker
Worker responsibilities:
dispatch outbound API calls
manage retries with backoff
transition internal state machines based on outcomes
surface failures into Admin/Ops exception queues
Failure handling & escalation
External failures are classified into:
transient (retryable)
terminal (manual review required)
Manual intervention actions (retry, cancel, substitute, pause) must:
be role-gated
auditable
Vendor abstraction & swap-ability
External providers are accessed via provider-specific adapters behind stable internal interfaces
Core domain logic must not depend on vendor-specific payloads or semantics
Provider configuration (API keys, endpoints, feature flags) is data-driven and managed via Admin/Ops tooling where possible.
Observability & monitoring