Procurement Readiness Packet
This packet is the buyer-facing operational summary for controlled beta and concierge paid pilots. It packages the security, hosting, data-flow, backup, and incident-response facts that a small museum, archive, lab, or foundation will ask for before sharing source collection data.
It is not a SOC 2 report, DPA, insurance certificate, or legal contract. Treat it as the current technical evidence packet that can support procurement conversations while the product is still in controlled beta and concierge pilot mode.
Scope
Use this packet for:
- Managed Linked Art Launch Pilot conversations
- controlled beta launch reviews
- lightweight vendor/security questionnaires
- internal readiness reviews before a customer source export is accepted
Do not use this packet to claim:
- broad public production readiness
- automated multi-tenant isolation
- recurring revenue proof
- formal compliance certification
- customer-specific legal commitments
Security Overview
Meta Museum is a source-backed Linked Art web application for rights-aware collection data publication and review.
Current controls:
- Auth.js v5 protects write and workspace routes.
- Public read routes expose source-backed records, docs, trust pages, and JSON endpoints.
- Postgres is the storage-of-record target for managed documents in launch mode.
- Sensitive records receive `_sensitivity` review state before public projection.
- PII and culturally sensitive terms are held for review until audited human disposition.
- Publication workflows require human approval before public claims are made.
- Agent outputs are review-only and must cite source records or refuse.
- Deployment preflight requires production secrets and database SSL verification before launch claims.
Current limits:
- Tenant isolation is not complete; paid pilots require explicit namespace discipline.
- Billing and plan gates are manual for pilots.
- Production support impersonation is not available.
- Production SLO, uptime, and external adoption evidence are still roadmap gates.
- Formal compliance artifacts are not yet packaged beyond this technical packet.
Support Access And Impersonation Policy
Meta Museum does not currently provide a production support-as-customer or impersonation feature. Operators must not use active-org cookies, pilot tenant headers, test role overrides, direct storage edits, or customer credentials to bypass customer membership, role, or org-admin gates.
Before any support impersonation feature ships, it must satisfy all of these controls:
- Explicit authorization: the customer organization, support operator, purpose, and affected scope are recorded before access begins.
- Scoped access: the support session is bound to one org or pilot tenant and cannot list, inspect, mutate, or export sibling org data.
- Time-bound access: the session expires automatically and cannot become a standing privilege.
- Audited access: every support session start, action, export, and end is written to the org-scoped audit log and is available in the next evidence packet.
- No admin bypass: support access cannot add memberships, create or revoke invites, export org audit packets, or change plan/entitlement state unless the operator also has the normal admin role required by those routes.
- Test-backed release: route tests must prove non-admin and non-member denial paths, scoped audit rows, and expiry behavior before the feature can be enabled in a pilot or production deployment.
Until those controls and tests exist, support is advisory: operators can inspect customer-supplied screenshots, exports, logs, or evidence packets, but they cannot act as the customer inside the application.
Data Flow
flowchart LR
Customer["Customer source export or bounded API"] --> Intake["Operator intake and namespace assignment"]
Intake --> Import["Provider/import adapter"]
Import --> Normalize["Linked Art normalization"]
Normalize --> Storage["Postgres managed storage or local managed document store"]
Storage --> Review["Validation, rights, sensitivity, reconciliation, and agent review queues"]
Review --> PublicRead["Public browse/API/docs surfaces after approval"]
Review --> Evidence["Pilot evidence packet and launch review artifacts"]
Operational boundaries:
- Customer source data must enter through a named source namespace.
- Raw provider/source payloads are preserved as provenance and are not mutated in place.
- Public HTML pages and JSON endpoints are read surfaces, not source-of-truth editing surfaces.
- AI and agent outputs do not publish directly; human approval gates remain required.
- Held or sensitive records must remain out of public Solr/GraphDB projection until approved.
Hosting And Subprocessors
Current deployment assumptions:
| Area | Current position |
|---|---|
| Application hosting | Hosted Next.js deployment target, selected during launch/staging setup. |
| Database | Neon-backed Postgres 16 for managed storage in launch mode. |
| Search | Solr 9 target for search indexing when the search stack is enabled. |
| Graph | GraphDB target for named graph publication when the graph stack is enabled. |
| Authentication | Auth.js v5 with GitHub OAuth credentials for sign-in where configured. |
| Observability | OpenTelemetry-compatible local/deployed evidence hooks; production sink is deployment-specific. |
| AI provider | OpenAI-compatible AI usage only where configured by deployment secrets. |
Procurement notes:
- Subprocessor and hosting commitments must match the actual deployment target chosen for the customer.
- Do not promise a fixed subprocessor list until deployment hosting, database, AI provider, and observability sinks are confirmed.
- For pilots, include the active deployment target, database host, AI provider status, and observability sink in the monthly evidence packet.
Backup And Restore Evidence
Current proof path:
- `pnpm storage:export:postgres` exports managed documents into the configured Postgres storage mode.
- `pnpm dr:drill` verifies a restore rehearsal and writes DR evidence.
- `pnpm launch:preflight` checks that the latest DR artifact is fresh enough for launch review.
- `pnpm launch:review` includes DR evidence in the launch decision packet.
Buyer-facing evidence to attach:
- latest DR drill artifact path
- restore rehearsal timestamp
- storage mode used for rehearsal
- managed document count restored
- known caveats or warnings
For pilots, attach this evidence to the monthly packet before representing the workspace as procurement-ready.
Incident Response Summary
Severity levels:
| Severity | Examples | Response posture |
|---|---|---|
| `blocking` | Customer cannot access workspace; import is blocked; public page exposes incorrect sensitive data. | Next-business-day response for pilots; immediate containment for public exposure. |
| `high` | Incorrect rights/publication state; failed launch preflight; evidence artifact missing before review. | Triage within two business days; document owner and next action. |
| `normal` | Mapping question, metadata correction, non-blocking UI issue, evidence clarification. | Weekly pilot review cadence. |
| `question` | Buyer questionnaire item, scope clarification, roadmap request. | Respond during normal pilot support cadence. |
Incident handling steps:
- Record requester, tenant/source namespace, severity, affected record/source, and current public exposure.
- Contain public exposure first when sensitivity, rights, or provenance risk is involved.
- Preserve source evidence and logs; do not mutate `_source.raw`.
- Assign owner and next response date.
- Document resolution summary and follow-up prevention item.
- Include customer-visible incident summary in the next evidence packet when the issue affects pilot outcomes.
Procurement Checklist
Before a pilot is described as procurement-ready, confirm:
- security overview has been shared
- data-flow summary has been shared
- active hosting/subprocessor assumptions are listed
- backup/restore evidence is attached
- incident response summary is attached
- pilot namespace and publication boundary are recorded
- manual entitlement record exists
- customer review owner is named
- unresolved risks are listed plainly
Related Evidence
- `docs/ops/managed-linked-art-pilot-runbook.md`
- `docs/ops/deployment-preflight.md`
- `docs/ops/launch-review.md`
- `docs/risk-register.md`
- `docs/roadmap.md`