Client Portal

Situation

Customers may need one place to access records, requests, documents, and workflow status. When servicing happens through email, copied files, and manual status updates, the customer and internal operator can hold different versions of the same state.

This reference explores a structured portal response to that situation. It is not evidence of a customer deployment or a live multi-tenant service.

Intended users

• Customers viewing their own records, documents, and request state.
• Client administrators managing access within one account boundary.
• Internal account operators publishing updates and resolving access problems.

The roles are modeled audiences. No named or verified user population is attached to this reference.

Constraints

• Every customer-facing record needs an explicit account or tenant boundary.
• Occasional users need a recoverable path when authentication links expire or have already been used.
• File access needs authorization at issuance and a bounded exposure window.
• Customer-visible status can become stale when it is edited independently from the events that created it.
• Duplicate customer requests and retries can occur during partial completion.
• Inbox-based authentication narrows password friction but inherits inbox compromise risk.
• Mobile and accessible access are design considerations, not verified implementation evidence in this repository.

The prior narrative described 15-minute magic links and 60-second file URLs as design parameters. No executable portal verifies those timings, so this page treats them as illustrative choices rather than operating facts.

What the reference models

Modeled tenant boundary. Tenant-owned records carry a tenant identifier, and the design places isolation at both the query and database-policy boundary. The included policy shape is illustrative; no database or policy test artifact exists here.

Modeled authentication recovery. A single-use link can expire into a re-request state instead of an unrecoverable error. The design makes the failed-authentication path part of the product journey.

Modeled document access. The server checks tenant and role scope before issuing a short-lived storage URL. This demonstrates a bounded-access decision, not a verified storage implementation.

Modeled status history. Workflow status is derived from append-only events rather than a manually edited label, so the design can show how a visible history and current state relate.

Deferred capability. No public portal, authentication provider configuration, database policy, storage bucket, two-tenant fixture, document workflow, or executable account experience is linked.

Critical failure modes

• TENANT_DATA_LEAK — one account can request or infer records belonging to another account.
• EXPIRED_LINK_DEAD_END — an old or consumed sign-in link leaves the customer without a safe next step.
• FILE_ACCESS_WITHOUT_SCOPE — a document URL remains usable without a current tenant and role decision.
• STALE_STATUS_STATE — the displayed workflow status no longer matches the underlying event history.
• DUPLICATE_CUSTOMER_REQUEST — a retry creates a second request while the first is only partially complete.
• PARTIAL_DOCUMENT_DELIVERY — metadata says a document is available while storage issuance or retrieval fails.

These are modeled failure conditions. The page does not claim complete prevention or verified persistence-layer enforcement.

Decisions and trade-offs

Database policy as a floor over query discipline alone

• Decision: Model tenant isolation below the interface and application query layer.
• Reason: A forgotten application filter should fail closed rather than return another account’s data.
• Trade-off: Policy context and debugging become more complex, and every table still needs deliberate coverage.
• Does not solve: Incorrect identity claims, privileged bypass access, storage misconfiguration, or missing policy tests.

Recoverable magic links over password accounts

• Decision: Model occasional access through bounded, single-use links with an explicit re-request state.
• Reason: Occasional users should not encounter password-reset friction as the main portal experience.
• Trade-off: Authentication security depends on the user’s email account and reliable message delivery.
• Does not solve: Inbox compromise, delivery failure, phishing, or account-recovery policy.

Event history over an editable status field

• Decision: Derive visible state from append-only workflow events.
• Reason: A status label should remain connected to the actions that produced it.
• Trade-off: Corrections require compensating events and a clearer state model.
• Does not solve: Missing events, incorrect event semantics, or delayed publication to the customer.

Verification performed

The public repository verifies:

• This MDX narrative and Reference build frontmatter exist.
• The static Work route can render the narrative, status qualification, evidence table, metadata, related services, and CTA.
• Repository tests can check content contracts, canonical metadata, sitemap inclusion, and evidence-safe wording.
• The production website build can verify the public evidence page compiles.

The previously described two-tenant fixture is not present in this repository and is no longer claimed as executed. No executable portal, authentication test, RLS test, storage test, public demo, production deployment, customer acceptance test, penetration test, or independent audit is linked.

Outcome

The reference demonstrates how customer access, tenant boundaries, document delivery, authentication recovery, and workflow history can be structured as one client-facing product. It is a design reference for future product scoping, not a verified customer or production outcome.

Current status

What is deliberately not handled

• A full customer-support CRM.
• Every document, request, approval, or billing workflow.
• Payment processing.
• Native mobile applications.
• Regulatory compliance certification.
• Verified identity-provider, database, or storage enforcement.
• Production availability, performance, scale, or customer adoption claims.