Security, continuity, and operations
Review product behavior, production configuration, provider commitments, and customer agreement as one implementation record.
Reference version 1.1 · Updated September 4, 2026
Control domains
| Domain | Implementation expectation |
|---|---|
| Identity and access | Authenticated accounts, assigned roles, privileged-access controls, and verified tokens. |
| Tenant isolation | Tenant-scoped relational rows, dedicated vector namespaces or collections, and namespaced object storage. |
| Encryption | TLS 1.3 in transit and AES-256 at rest for applicable managed services. |
| Model use | Customer data processed under applicable zero-training commercial terms. |
| Execution isolation | Network-disabled sandboxes for managed deep-review tasks where configured. |
| Lifecycle | Documented residency, retention, deletion, backup, and restoration behavior. |
| Human governance | Named review and release gates before approved external action. |
Map the complete data path
- Who makes the request and which resource is authorized?
- Which application, worker, model endpoint, sandbox, and storage service handles each stage?
- Where do source PDFs, extracted text, embeddings, page artifacts, dossiers, reports, and backups travel?
- How do retention, deletion, recovery, and customer handoff work?
Continuity evidence
Record recovery objectives, backup coverage, restoration procedure, exercise date, observed recovery result, data-loss result, and open corrective actions. Treat targets and observed evidence as different fields.
Detail: failure and recovery behavior
| Control | Behavior |
|---|---|
| Attempt ownership | A stale background attempt cannot replace the state written by a newer worker. |
| Resume by provenance | Indexed pages can be reused only when source hash, embedding model/schema, and required assets still match. |
| Page-level isolation | One failed page does not automatically discard successful pages from the same document. |
| Marked fallback | Available text and raw assets can remain as an explicitly stubbed page when visual analysis fails. |
| Retained original | The source PDF remains available for citations, resume, and verification-packet assembly. |
| Report-level trace | Warnings, audit entries, methodology, measurements, questions, context coverage, and sources travel with the report. |
Detail: recovery objectives
RTO is the target time to restore service. RPO is the target recoverable data-loss window. These operational targets are distinct from the observed results below and from any customer-specific agreement.
| Tier | RTO target | RPO target | Recovery method |
|---|---|---|---|
| API and compute | < 15 minutes | 0 minutes | Stateless multi-zone services and revision rollback |
| Relational database | < 1 hour | < 5 minutes | WAL, snapshots, and point-in-time recovery |
| File and artifact storage | < 30 minutes | < 1 hour | Redundant object storage and source-hash verification |
| Vector search store | < 2 hours | < 4 hours | Re-indexing from primary document metadata and source files |
Recorded recovery exercise: August 4, 2026
The recorded production-mirror exercise reported 100% recovery success, zero data loss, and zero open corrective actions. The table preserves measured timings separately from recovery objectives.
| Path | Measured recovery | Target | Recorded outcome |
|---|---|---|---|
| Application compute | 3 min 45 sec | < 15 min | Passed |
| Database failover | 18 min 20 sec | < 60 min | Passed · zero records lost |
| Storage linkage | 4 min 10 sec | < 30 min | Passed |
| Vector re-ingestion | 42 min 15 sec | < 120 min | Passed |
Need help applying this page to an evaluation?Ask a product question