{"id":"ops/procurement-readiness-packet","relativePath":"ops/procurement-readiness-packet.md","title":"Procurement Readiness Packet","markdown":"# Procurement Readiness Packet\n\nThis 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.\n\nIt 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.\n\n## Scope\n\nUse this packet for:\n\n- Managed Linked Art Launch Pilot conversations\n- controlled beta launch reviews\n- lightweight vendor/security questionnaires\n- internal readiness reviews before a customer source export is accepted\n\nDo not use this packet to claim:\n\n- broad public production readiness\n- automated multi-tenant isolation\n- recurring revenue proof\n- formal compliance certification\n- customer-specific legal commitments\n\n## Security Overview\n\nMeta Museum is a source-backed Linked Art web application for rights-aware collection data publication and review.\n\nCurrent controls:\n\n- Auth.js v5 protects write and workspace routes.\n- Public read routes expose source-backed records, docs, trust pages, and JSON endpoints.\n- Postgres is the storage-of-record target for managed documents in launch mode.\n- Sensitive records receive `_sensitivity` review state before public projection.\n- PII and culturally sensitive terms are held for review until audited human disposition.\n- Publication workflows require human approval before public claims are made.\n- Agent outputs are review-only and must cite source records or refuse.\n- Deployment preflight requires production secrets and database SSL verification before launch claims.\n\nCurrent limits:\n\n- Tenant isolation is not complete; paid pilots require explicit namespace discipline.\n- Billing and plan gates are manual for pilots.\n- Production support impersonation is not available.\n- Production SLO, uptime, and external adoption evidence are still roadmap gates.\n- Formal compliance artifacts are not yet packaged beyond this technical packet.\n\n## Support Access And Impersonation Policy\n\nMeta 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.\n\nBefore any support impersonation feature ships, it must satisfy all of these controls:\n\n- Explicit authorization: the customer organization, support operator, purpose, and affected scope are recorded before access begins.\n- Scoped access: the support session is bound to one org or pilot tenant and cannot list, inspect, mutate, or export sibling org data.\n- Time-bound access: the session expires automatically and cannot become a standing privilege.\n- 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.\n- 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.\n- 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.\n\nUntil 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.\n\n## Data Flow\n\n```mermaid\nflowchart LR\n  Customer[\"Customer source export or bounded API\"] --> Intake[\"Operator intake and namespace assignment\"]\n  Intake --> Import[\"Provider/import adapter\"]\n  Import --> Normalize[\"Linked Art normalization\"]\n  Normalize --> Storage[\"Postgres managed storage or local managed document store\"]\n  Storage --> Review[\"Validation, rights, sensitivity, reconciliation, and agent review queues\"]\n  Review --> PublicRead[\"Public browse/API/docs surfaces after approval\"]\n  Review --> Evidence[\"Pilot evidence packet and launch review artifacts\"]\n```\n\nOperational boundaries:\n\n- Customer source data must enter through a named source namespace.\n- Raw provider/source payloads are preserved as provenance and are not mutated in place.\n- Public HTML pages and JSON endpoints are read surfaces, not source-of-truth editing surfaces.\n- AI and agent outputs do not publish directly; human approval gates remain required.\n- Held or sensitive records must remain out of public Solr/GraphDB projection until approved.\n\n## Hosting And Subprocessors\n\nCurrent deployment assumptions:\n\n| Area | Current position |\n|---|---|\n| Application hosting | Hosted Next.js deployment target, selected during launch/staging setup. |\n| Database | Neon-backed Postgres 16 for managed storage in launch mode. |\n| Search | Solr 9 target for search indexing when the search stack is enabled. |\n| Graph | GraphDB target for named graph publication when the graph stack is enabled. |\n| Authentication | Auth.js v5 with GitHub OAuth credentials for sign-in where configured. |\n| Observability | OpenTelemetry-compatible local/deployed evidence hooks; production sink is deployment-specific. |\n| AI provider | OpenAI-compatible AI usage only where configured by deployment secrets. |\n\nProcurement notes:\n\n- Subprocessor and hosting commitments must match the actual deployment target chosen for the customer.\n- Do not promise a fixed subprocessor list until deployment hosting, database, AI provider, and observability sinks are confirmed.\n- For pilots, include the active deployment target, database host, AI provider status, and observability sink in the monthly evidence packet.\n\n## Backup And Restore Evidence\n\nCurrent proof path:\n\n- `pnpm storage:export:postgres` exports managed documents into the configured Postgres storage mode.\n- `pnpm dr:drill` verifies a restore rehearsal and writes DR evidence.\n- `pnpm launch:preflight` checks that the latest DR artifact is fresh enough for launch review.\n- `pnpm launch:review` includes DR evidence in the launch decision packet.\n\nBuyer-facing evidence to attach:\n\n- latest DR drill artifact path\n- restore rehearsal timestamp\n- storage mode used for rehearsal\n- managed document count restored\n- known caveats or warnings\n\nFor pilots, attach this evidence to the monthly packet before representing the workspace as procurement-ready.\n\n## Incident Response Summary\n\nSeverity levels:\n\n| Severity | Examples | Response posture |\n|---|---|---|\n| `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. |\n| `high` | Incorrect rights/publication state; failed launch preflight; evidence artifact missing before review. | Triage within two business days; document owner and next action. |\n| `normal` | Mapping question, metadata correction, non-blocking UI issue, evidence clarification. | Weekly pilot review cadence. |\n| `question` | Buyer questionnaire item, scope clarification, roadmap request. | Respond during normal pilot support cadence. |\n\nIncident handling steps:\n\n1. Record requester, tenant/source namespace, severity, affected record/source, and current public exposure.\n2. Contain public exposure first when sensitivity, rights, or provenance risk is involved.\n3. Preserve source evidence and logs; do not mutate `_source.raw`.\n4. Assign owner and next response date.\n5. Document resolution summary and follow-up prevention item.\n6. Include customer-visible incident summary in the next evidence packet when the issue affects pilot outcomes.\n\n## Procurement Checklist\n\nBefore a pilot is described as procurement-ready, confirm:\n\n- security overview has been shared\n- data-flow summary has been shared\n- active hosting/subprocessor assumptions are listed\n- backup/restore evidence is attached\n- incident response summary is attached\n- pilot namespace and publication boundary are recorded\n- manual entitlement record exists\n- customer review owner is named\n- unresolved risks are listed plainly\n\n## Related Evidence\n\n- `docs/ops/managed-linked-art-pilot-runbook.md`\n- `docs/ops/deployment-preflight.md`\n- `docs/ops/launch-review.md`\n- `docs/risk-register.md`\n- `docs/roadmap.md`\n","sections":[{"level":2,"heading":"Scope","anchor":"scope"},{"level":2,"heading":"Security Overview","anchor":"security-overview"},{"level":2,"heading":"Support Access And Impersonation Policy","anchor":"support-access-and-impersonation-policy"},{"level":2,"heading":"Data Flow","anchor":"data-flow"},{"level":2,"heading":"Hosting And Subprocessors","anchor":"hosting-and-subprocessors"},{"level":2,"heading":"Backup And Restore Evidence","anchor":"backup-and-restore-evidence"},{"level":2,"heading":"Incident Response Summary","anchor":"incident-response-summary"},{"level":2,"heading":"Procurement Checklist","anchor":"procurement-checklist"},{"level":2,"heading":"Related Evidence","anchor":"related-evidence"}],"html":"<h1 id=\"procurement-readiness-packet\">Procurement Readiness Packet</h1>\n<p>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.</p>\n<p>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.</p>\n<h2 id=\"scope\">Scope</h2>\n<p>Use this packet for:</p>\n<ul><li>Managed Linked Art Launch Pilot conversations</li><li>controlled beta launch reviews</li><li>lightweight vendor/security questionnaires</li><li>internal readiness reviews before a customer source export is accepted</li></ul>\n<p>Do not use this packet to claim:</p>\n<ul><li>broad public production readiness</li><li>automated multi-tenant isolation</li><li>recurring revenue proof</li><li>formal compliance certification</li><li>customer-specific legal commitments</li></ul>\n<h2 id=\"security-overview\">Security Overview</h2>\n<p>Meta Museum is a source-backed Linked Art web application for rights-aware collection data publication and review.</p>\n<p>Current controls:</p>\n<ul><li>Auth.js v5 protects write and workspace routes.</li><li>Public read routes expose source-backed records, docs, trust pages, and JSON endpoints.</li><li>Postgres is the storage-of-record target for managed documents in launch mode.</li><li>Sensitive records receive `_sensitivity` review state before public projection.</li><li>PII and culturally sensitive terms are held for review until audited human disposition.</li><li>Publication workflows require human approval before public claims are made.</li><li>Agent outputs are review-only and must cite source records or refuse.</li><li>Deployment preflight requires production secrets and database SSL verification before launch claims.</li></ul>\n<p>Current limits:</p>\n<ul><li>Tenant isolation is not complete; paid pilots require explicit namespace discipline.</li><li>Billing and plan gates are manual for pilots.</li><li>Production support impersonation is not available.</li><li>Production SLO, uptime, and external adoption evidence are still roadmap gates.</li><li>Formal compliance artifacts are not yet packaged beyond this technical packet.</li></ul>\n<h2 id=\"support-access-and-impersonation-policy\">Support Access And Impersonation Policy</h2>\n<p>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.</p>\n<p>Before any support impersonation feature ships, it must satisfy all of these controls:</p>\n<ul><li>Explicit authorization: the customer organization, support operator, purpose, and affected scope are recorded before access begins.</li><li>Scoped access: the support session is bound to one org or pilot tenant and cannot list, inspect, mutate, or export sibling org data.</li><li>Time-bound access: the session expires automatically and cannot become a standing privilege.</li><li>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.</li><li>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.</li><li>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.</li></ul>\n<p>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.</p>\n<h2 id=\"data-flow\">Data Flow</h2>\n<pre><code>\nflowchart LR\n  Customer[&quot;Customer source export or bounded API&quot;] --&gt; Intake[&quot;Operator intake and namespace assignment&quot;]\n  Intake --&gt; Import[&quot;Provider/import adapter&quot;]\n  Import --&gt; Normalize[&quot;Linked Art normalization&quot;]\n  Normalize --&gt; Storage[&quot;Postgres managed storage or local managed document store&quot;]\n  Storage --&gt; Review[&quot;Validation, rights, sensitivity, reconciliation, and agent review queues&quot;]\n  Review --&gt; PublicRead[&quot;Public browse/API/docs surfaces after approval&quot;]\n  Review --&gt; Evidence[&quot;Pilot evidence packet and launch review artifacts&quot;]\n</code></pre>\n<p>Operational boundaries:</p>\n<ul><li>Customer source data must enter through a named source namespace.</li><li>Raw provider/source payloads are preserved as provenance and are not mutated in place.</li><li>Public HTML pages and JSON endpoints are read surfaces, not source-of-truth editing surfaces.</li><li>AI and agent outputs do not publish directly; human approval gates remain required.</li><li>Held or sensitive records must remain out of public Solr/GraphDB projection until approved.</li></ul>\n<h2 id=\"hosting-and-subprocessors\">Hosting And Subprocessors</h2>\n<p>Current deployment assumptions:</p>\n<p>| Area | Current position |</p>\n<p>|---|---|</p>\n<p>| Application hosting | Hosted Next.js deployment target, selected during launch/staging setup. |</p>\n<p>| Database | Neon-backed Postgres 16 for managed storage in launch mode. |</p>\n<p>| Search | Solr 9 target for search indexing when the search stack is enabled. |</p>\n<p>| Graph | GraphDB target for named graph publication when the graph stack is enabled. |</p>\n<p>| Authentication | Auth.js v5 with GitHub OAuth credentials for sign-in where configured. |</p>\n<p>| Observability | OpenTelemetry-compatible local/deployed evidence hooks; production sink is deployment-specific. |</p>\n<p>| AI provider | OpenAI-compatible AI usage only where configured by deployment secrets. |</p>\n<p>Procurement notes:</p>\n<ul><li>Subprocessor and hosting commitments must match the actual deployment target chosen for the customer.</li><li>Do not promise a fixed subprocessor list until deployment hosting, database, AI provider, and observability sinks are confirmed.</li><li>For pilots, include the active deployment target, database host, AI provider status, and observability sink in the monthly evidence packet.</li></ul>\n<h2 id=\"backup-and-restore-evidence\">Backup And Restore Evidence</h2>\n<p>Current proof path:</p>\n<ul><li>`pnpm storage:export:postgres` exports managed documents into the configured Postgres storage mode.</li><li>`pnpm dr:drill` verifies a restore rehearsal and writes DR evidence.</li><li>`pnpm launch:preflight` checks that the latest DR artifact is fresh enough for launch review.</li><li>`pnpm launch:review` includes DR evidence in the launch decision packet.</li></ul>\n<p>Buyer-facing evidence to attach:</p>\n<ul><li>latest DR drill artifact path</li><li>restore rehearsal timestamp</li><li>storage mode used for rehearsal</li><li>managed document count restored</li><li>known caveats or warnings</li></ul>\n<p>For pilots, attach this evidence to the monthly packet before representing the workspace as procurement-ready.</p>\n<h2 id=\"incident-response-summary\">Incident Response Summary</h2>\n<p>Severity levels:</p>\n<p>| Severity | Examples | Response posture |</p>\n<p>|---|---|---|</p>\n<p>| `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. |</p>\n<p>| `high` | Incorrect rights/publication state; failed launch preflight; evidence artifact missing before review. | Triage within two business days; document owner and next action. |</p>\n<p>| `normal` | Mapping question, metadata correction, non-blocking UI issue, evidence clarification. | Weekly pilot review cadence. |</p>\n<p>| `question` | Buyer questionnaire item, scope clarification, roadmap request. | Respond during normal pilot support cadence. |</p>\n<p>Incident handling steps:</p>\n<ol><li>Record requester, tenant/source namespace, severity, affected record/source, and current public exposure.</li></ol>\n<ol><li>Contain public exposure first when sensitivity, rights, or provenance risk is involved.</li></ol>\n<ol><li>Preserve source evidence and logs; do not mutate `_source.raw`.</li></ol>\n<ol><li>Assign owner and next response date.</li></ol>\n<ol><li>Document resolution summary and follow-up prevention item.</li></ol>\n<ol><li>Include customer-visible incident summary in the next evidence packet when the issue affects pilot outcomes.</li></ol>\n<h2 id=\"procurement-checklist\">Procurement Checklist</h2>\n<p>Before a pilot is described as procurement-ready, confirm:</p>\n<ul><li>security overview has been shared</li><li>data-flow summary has been shared</li><li>active hosting/subprocessor assumptions are listed</li><li>backup/restore evidence is attached</li><li>incident response summary is attached</li><li>pilot namespace and publication boundary are recorded</li><li>manual entitlement record exists</li><li>customer review owner is named</li><li>unresolved risks are listed plainly</li></ul>\n<h2 id=\"related-evidence\">Related Evidence</h2>\n<ul><li>`docs/ops/managed-linked-art-pilot-runbook.md`</li><li>`docs/ops/deployment-preflight.md`</li><li>`docs/ops/launch-review.md`</li><li>`docs/risk-register.md`</li><li>`docs/roadmap.md`</li></ul>","updatedAt":"2018-10-20T01:46:40.000Z","checksum":"c5685e82cca7f7e83b304890567bec8ad47f0d7a517ef52076c1b7f80f0c928f","checksumPrefix":"c5685e82cca7","anchorCount":9,"lineCount":163,"rawUrl":"/api/docs/content?path=ops%2Fprocurement-readiness-packet.md","htmlUrl":"/docs?doc=ops%2Fprocurement-readiness-packet.md","apiUrl":"/api/docs/content?path=ops%2Fprocurement-readiness-packet.md"}