Trust Center

Scope

Trust communication should reflect actual operating posture, not get ahead of it. This guide keeps the customer-facing workflow guidance and excludes private publishing or implementation mechanics.

Workstream: WS-16

Overview

The Trust Center is your organization’s public-facing compliance page. Use it to share certifications, security overviews, and controlled-access documents with prospects, partners, and customers.

Key rule: The trust center never auto-publishes from internal compliance status. Everything that appears publicly is something an operator intentionally added and published.

Building Your Trust Center

Step 1: Create the Trust Center

1. Navigate to Settings → Trust Center.
2. If no trust center exists yet, a setup form appears.
3. Enter a URL Slug (e.g. your-company) — this becomes your public URL: the relevant workflow. - Lowercase letters, digits, and hyphens only. - Choose carefully; changing the slug after publishing breaks existing links.
4. Enter a Title (e.g. “Acme Corp Trust Center”).
5. Optionally add a Description.
6. Click Create Trust Center.

The trust center is created in draft (unpublished) state. Visitors cannot see it yet.

Step 1b: Upload a Logo (Optional)

From the Overview tab, click Upload Logo to add your company logo to the trust center.

• Accepted formats: PNG and JPEG only. SVG is rejected (XSS surface).
• Maximum file size: 5 MB.
• The logo appears at the top of your public trust center page.
• To replace it, upload a new image. The old image is replaced immediately.

Added in Wave 05 (T-05.7). Closes G-P0-29.

Step 2: Add Content

Navigate to the Sections tab to add content blocks.

Each section has:

• Title — displayed as a heading on the public page
• Content — Markdown text. The public page renders headings, lists, emphasis, and links from this Markdown. Use it for security overview narrative, subprocessor lists, FAQs, and similar copy.
• Visibility — toggle sections visible/hidden without deleting them

Use the Hide/Show button to control which sections appear on the public page without losing your draft content.

Step 3: Add Certifications

Navigate to the Certifications tab.

Important: Certifications are entered manually. Internal compliance program status does NOT automatically populate this section. Adding a certification here is a deliberate publication decision.

For each certification:

• Framework Name — e.g. “SOC 2 Type II”, “ISO 27001:2022”, “HIPAA”
• Auditor Firm — the audit firm that issued the certification
• Display Badge — whether to show in the badge strip at the top of the public page

Certifications with Display Badge enabled and status: current appear prominently in the header.

Step 4: Add Documents

Navigate to the Documents tab.

For each document:

1. Click + Add Document.
2. Set the title, optional description, document type, and access level.
3. Click Add. The document is registered (the file attachment step is separate).

Fileless behavior is tier-specific under a published Trust Center:

Access level	Fileless metadata	Request behavior	Delivery
NDA Required	Visible immediately	Visitor e-signs the NDA and may create a pending request	Upload and approve before delivery
Request Only	Visible immediately	Visitor may create a pending request	Upload and approve before delivery

The create form warns about this cutover. Do not use nda_required or request_only as a private staging state on a published Trust Center. Review existing fileless gated rows before deployment because their approved metadata becomes anonymously discoverable. Protected bytes are never delivered before upload and approval.

Access Levels

Level	Who can download	Process
Public	Anyone, immediately	None — the public page resolves a download URL and the browser navigates straight to the document content
NDA Required	Anyone who e-signs the NDA	Submit request form → operator approval
Request Only	Anyone approved by an operator	Submit request form → operator approval

Choose access levels carefully. A SOC 2 Type II full report typically warrants nda_required. A security overview policy might be public.

Storage Quota

Trust-center documents count against your plan’s storage volume (total bytes of uploaded files), shown at the top of the Documents tab as “Storage used: X of Y”. When an upload would exceed the plan limit you get a clear over-limit message with an upgrade suggestion instead of the upload proceeding. Replacing a file with one of the same size or smaller always succeeds. Deleting a document frees its storage immediately (the stored file is removed too). Full usage across all plan resources is on Settings → Plan.

Automatic Removal of Stale Documents (Retention)

On the Overview tab, the Automatically remove stale documents setting controls a per-trust-center retention policy:

• New trust centers default to 12 months. Trust centers created before this feature have retention off until you enable it.

• When enabled, a daily background sweep permanently removes any document whose current file is older than the retention window. The clock counts from the file’s last upload — re-uploading a fresh file (e.g. this year’s SOC 2 report into the same document) resets it.

• Every removal is recorded in the audit log, emits the trust_center.document_retention_removed platform event (subscribe via Settings → Webhooks/Events to get notified), and — for public documents — posts a “Document removed” update on the public page.

• Turning the toggle off (or clearing the months value) stops all automatic removal; nothing is deleted retroactively when you change the window.

Removal is permanent — the file is deleted from storage. If you need a document preserved indefinitely, disable retention or re-upload the file to reset its clock before the window elapses.

Step 5: Custom Domain DNS Ownership

You can prove ownership of a custom trust-center domain (e.g. trust.yourcompany.com) with a two-step TXT challenge. After verification and publication, visitors can use that domain as the public Trust Center URL. Meridian serves the public page, document handoff links, and public Trust Center API calls for the verified host.

Step 5a: Initiate the domain claim

1. In the Overview tab, find the Custom Domain field.
2. Enter your domain (e.g. trust.yourcompany.com) and click Start Verification.

Field	Example value
Record name	_meridian-trust-center.trust.yourcompany.com
Record type	TXT
Record value	a3f1b2c4d5e6... (32-char hex token)

4. Create this TXT record in your DNS provider. DNS propagation typically takes a few minutes to 48 hours.

Step 5b: Verify ownership

Once your DNS record has propagated:

1. Return to Settings → Trust Center → Overview.
2. Click Verify Domain.
3. If the token is found, the domain is marked verified and backend custom-domain dispatch cache is refreshed immediately (no TTL wait).

You can retry Verify Domain as often as needed. The page always shows the current verified / not verified state.

Note: Re-running Start Verification on a new domain resets the token and clears the verified state, requiring a new verification pass.

Step 5c: Use the supported visitor URL

If the custom domain returns a plain 503 frontend-deployment error, DNS ownership is verified but the backend deployment does not have pointed at the built frontend assets. Fix deployment configuration before sharing the domain.

Step 6: Publish

When you’re ready for the public to see the trust center:

1. Click the Publish button in the top-right corner.
2. Confirm the prompt.
3. The badge changes to Published. The public URL (the relevant workflow) is now live.

Optional: Show Program Readiness on the Public Page

In the Overview tab, enable Show internal program readiness on the public page only when you intentionally want prospects or auditors to see readiness percentages for active and in-audit compliance programs. Leave it off by default; publishing the trust center does not publish internal readiness unless this toggle is enabled.

Managing Document Access Requests

Operators can preview the external request experience for any NDA-required or request-only document from the Documents tab. The preview is deliberately non-mutating: it does not load the live public page, publish or upload a file, create a request or visit, consume a challenge, write an audit/update event, mint a token, grant access, or send email. Preview consequence text states the real NDA/review and file-availability requirements without mounting a live request form.

Navigate to Settings → Trust Center → Document Requests.

The Documents tab also links directly to this queue and explains that nda_required and request_only documents are not completed from the document card itself. This keeps the gated-document handoff discoverable while editing the document catalog.

The request queue validates the complete paginated response before presenting it as operator truth. If the service returns a malformed request, NDA evidence record, page envelope, or review response, Meridian shows an invalid-response error and does not render or confirm a partial state. Status-filter and pagination requests are sequenced so a slower previous response cannot overwrite the newest selection. Approve and deny are single-flight per request; repeated clicks cannot submit the same review twice while it is unresolved. If copying an approved download link fails, the queue reports that failure instead of claiming the link was copied.

The Documents tab’s Review requests control uses in-application navigation to preserve the authenticated shell and operator orientation; it does not force a full-page reload. The request queue is server-paginated. Use the status filters and page controls to review large histories; the UI does not load every request into the browser and then slice locally.

Reviewing Pending Requests

Pending requests show:

• Requester name, email, and company
• The document they’re requesting
• Their stated reason
• E-signed NDA evidence when present: NDA version, signed timestamp, and the retained NDA text hash
• A warning when an nda_required request is missing the NDA acceptance record
• Whether a protected file is available. Fileless pending requests show an upload prerequisite, disable Approve, keep Deny enabled, and provide Upload document recovery.
• Submission date

Approving a Request

1. If Approve is disabled, click Upload document. Meridian opens the Documents tab and focuses the exact row.

2. Click Upload file (or Replace file), choose a valid unencrypted PDF for a gated document, and wait for the list to refresh.

3. Return to/refetch the request queue. Approve becomes available only when the authenticated queue reports the file exists.

4. Click Approve on the request.

5. Confirm the action. The backend rechecks file availability to protect stale or racing clients.
6. For nda_required, Meridian verifies canonical e-sign evidence. If missing, approval fails and the requester must submit a new request.
7. Meridian generates a single-use download link, valid until first successful download or 48 hours, and emails it after commit.
8. Use the Copy link toast action if another delivery channel is required.

Approved nda_required and request_only document downloads are stamped at download time with the requester email, requester company when supplied, the request id, and a timestamp. The original uploaded file is not modified. Public document downloads are not stamped. If a gated PDF is malformed or encrypted and cannot be stamped, the requester sees a download error; replace it with a valid, unencrypted PDF before approving a new request or asking the requester to retry.

Download analytics increment only when the requester hits the backend file content endpoint and Meridian serves the document response. Reviewing a request, copying the link, or loading the metadata handoff does not increment download_count. The request queue shows the downloaded timestamp after Meridian records download_token_used_at.

If the requester needs another download after using or losing the link, they must submit a new request. Approved and denied review states are terminal in this workflow; Meridian does not reissue a second token from the same reviewed request.

Denying a Request

1. Click Deny on the request.
2. Confirm the action.
3. The request is marked denied. This is a terminal state — you cannot re-approve a denied request. Create a new approval flow if needed.

Denial does not send an email. Public request confirmation therefore promises only pending review, not an email for every outcome.

Filtering

Use the status filter (Pending / Approved / Denied / All) to find specific requests.

Managing Visitor Subscriptions

Visitors can subscribe from the public Trust Center page to receive email digests when public-facing Trust Center content changes.

Visitor Flow

1. Visitor enters an email address, optional name/company, and checks the consent box.
2. Meridian sends a confirmation email. The subscription remains Pending until the visitor confirms.
3. Visitor opens the confirmation link. The subscription becomes Active.
4. Future public changes are included in hourly digest sweeps.
5. Visitor can unsubscribe from a digest link or from an unsubscribe link on the public page.

Subscribe responses are intentionally generic. They do not reveal whether an email address is already subscribed.

Operator View

Open Settings → Trust Center → Subscribers.

The subscriber list is server-paginated and filterable by status:

• Pending — confirmation email was requested but not confirmed.
• Active — confirmed and eligible for digests.
• Unsubscribed — retained history; no more digests are sent.

Operators with Meridian.manage can click Unsubscribe for any pending or active subscriber. This records an audit event and preserves the row for history.

The Subscribers workspace remains usable on a phone: each visitor is presented as a card with their identity, lifecycle status, confirmation/digest timestamps, and the same Unsubscribe action available in the desktop table. If an unsubscribe request fails, the existing subscriber state remains visible and Meridian shows the server error so the operator can retry safely.

Digest Timing And Recovery

The background scheduler sends Trust Center update digests hourly. The digest includes public-visible changes only: published Trust Center availability, visible section changes, public certification changes, discoverable document metadata visibility/edits/removals, document uploads, and branding changes. Fileless public drafts and preview interactions do not queue emails.

If a digest email fails, Meridian records a failed delivery row with the error and does not advance that subscriber’s cursor. The next sweep can retry the same event batch. One subscriber’s failure does not block other subscribers.

Troubleshooting:

• Pending subscribers did not get email: check outbound email configuration and application logs for trust_center.subscription_confirmation.
• Active subscribers did not get digests: confirm the Trust Center is published and that public-visible update events exist after the subscriber’s last digest cursor.
• Custom-domain unsubscribe links fail: confirm the custom domain is still verified and published; otherwise use the platform URL for the unsubscribe flow.

Updating Published Content

Changes to sections, certifications, and documents are saved immediately but do not re-publish or un-publish the trust center. If the trust center is published, visitors see changes in real time after you save.

This means:

• Adding a section while published → visible immediately.
• Hiding a section while published → hidden immediately.
• Changing a document’s access level while published → takes effect immediately.
• Changing a fileless public document to a gated tier → metadata becomes visible and requestable immediately.
• Changing a fileless gated document to public → metadata becomes hidden until upload.

To stage updates without showing visitors: unpublish first, make changes, then re-publish.

Frequently Asked Questions

A: The trust center must be explicitly published. Click Publish in the Trust Center Builder.

Q: Why does the public page show a network error or unavailable state? A: The browser reached the SPA, but the public trust-center API did not return usable data. Check public route deployment, API reachability, TLS/CORS on the public API host, and the live publish state before assuming the page itself is healthy. If the page shows a plain error state instead of a network error, the browser reached the API and the backend returned a real server failure that needs log-level investigation.

Q: Can I connect the Trust Center to my internal SOC 2 program status? A: No — this is intentional. The Trust Center certifications are manually managed. An internal program being “green” is not the same as having a certified audit with an auditor firm. You add certifications manually when you have an actual certification to advertise.

Q: A requester’s download link expired. Can I re-issue it? A: No — re-issuance is not automated. The requester should submit a new access request. Download tokens are valid for 48 hours.

Q: A request was submitted for a document I had not uploaded yet. The approval button now says “Cannot approve” — why?

Q: Can I change the slug after publishing? A: Yes, but this will break any existing bookmarks or links to the old slug. Make sure to update any external references.

Q: How do I prevent bots from submitting document access requests directly without going through the page?

Q: How does the custom domain work? A: Custom domains require a two-step DNS proof of ownership. First, use Start Verification to get a TXT record to publish at _meridian-trust-center.<your-domain>. After DNS propagates, click Verify Domain. Once verified and published, the custom host serves the public Trust Center page, document handoff links, and canonical public Trust Center API paths.

Permissions

All Trust Center admin actions require Meridian.manage permission.

The public trust center page (the relevant workflow) requires no authentication.