RELAYDESK SPECIFICATION — REVIEW FIXTURE V1 This is a fictional specification for an internal document-review service. Treat every numbered requirement as part of the same proposed release. Requirements describe desired behavior, not features that have been implemented. All durations are elapsed wall-clock durations unless a requirement says otherwise. All byte sizes use decimal units: one MB is 1,000,000 bytes. The specification is the complete evidence packet for the review exercise. PRODUCT SCOPE R01. RelayDesk accepts document-review jobs from authenticated workspace members. Each job belongs to one workspace and names exactly one uploaded source document. The first release produces a structured findings report and an audit trail; it does not edit the source document, send external messages, or execute generated code. R02. A workspace has owner, editor, and viewer roles. Owners manage membership and retention settings. Editors submit jobs and annotate findings. Viewers read completed reports. Workspace identifiers are included in every database key and authorization check; knowing an object identifier never grants permission to access the object. R03. Job submission returns a durable job identifier after the source document and job metadata have both been committed. A timeout before that acknowledgement does not establish whether submission succeeded. The client may repeat the same request with its original idempotency key and must receive the existing job identifier. R04. The supported source formats are plain UTF-8 text and PDF documents without password protection. A PDF with extraction errors is rejected with a reason before review starts. The service must not silently replace an unreadable document with an empty string, claim that the document contains no issues, or fabricate extracted text. R05. Every finding identifies a source passage, a requirement or heading reference, a severity, and a suggested correction. Findings must distinguish contradictory requirements from missing details and optional improvements. A report may contain zero findings when the supplied document supports no actionable issue. DATA AND RETENTION R06. Source documents, raw extracted text, and customer annotations are permanently deleted exactly 30 days after upload. This rule applies to all storage replicas, backups, temporary objects, and exports retained by RelayDesk. No reconstructable copy of that content may remain inside RelayDesk after the deletion deadline. R07. Job metadata may remain for one year after upload. Retained metadata consists only of the job identifier, workspace identifier, upload time, deletion time, terminal status, and aggregated token totals. It must not contain source passages, reversible encodings of source documents, customer annotations, or complete review reports. R08. The upload service stores a SHA-256 hash of each accepted source document while that document exists. Downloads must reproduce the original bytes and match the hash. The hash supports integrity checking; it is not an alternate copy of the source and cannot be used as a substitute for a requested full-document export. R09. Workspace owners may request earlier deletion of a source document. The service must stop new review work, remove readable document content, and mark affected reports unavailable. The user-facing status distinguishes this early deletion from a parsing failure, a provider timeout, and ordinary expiration under the retention policy. R10. Each database record stores the workspace identifier separately from the actor identifier. Actor identifiers may be pseudonymous. Internal analytics use aggregate job counts rather than customer document content. Product analytics must not copy raw documents into an independent warehouse with a different retention period. OFFLINE ACCESS AND PERMISSIONS R11. A managed desktop client supports 24 continuous hours of fully disconnected access after its last successful synchronization. During that entire period, an already authorized member can open cached reports without contacting any server. The client must not require a background network connection to maintain this access. R12. Cached report files are encrypted on the managed device. The client obtains the decryption material during synchronization and stores it using the operating system credential store. The release does not assume that a server can remotely erase an offline device or transmit a notification without a network connection. R13. Report downloads require a workspace membership check while the client is connected. The download endpoint returns a clear authorization failure if membership does not permit access. Such a failure must never be reinterpreted as a temporary storage outage or trigger an automatic attempt using another member's credentials. R14. The desktop client displays the time of its last successful synchronization. Reports viewed offline carry an offline indicator. An offline client cannot create new server-side review jobs, change membership, or claim that a queued local action has already been accepted by the server before a later synchronization completes. R15. Workspace membership changes are recorded centrally with a timestamp and the acting owner. The service can explain which membership record authorized a connected request. Clock readings from customer devices are not treated as authoritative for the ordering of server-side membership changes or account-recovery operations. QUEUE AND WORKER BEHAVIOR R16. A review worker makes at most five provider attempts for each job, including the first attempt. After the fifth failed attempt, the job becomes terminally failed. No worker, scheduler, operator action, or automatic retry may make a sixth provider attempt under the same job identifier, including after a worker process restarts. R17. Each attempt has an incrementing attempt number and durable timestamps for start and completion. Workers reserve attempt numbers transactionally before calling the provider. A worker crash does not reset the attempt count, and concurrently leased workers must not reserve or execute the same numbered attempt twice. R18. Retry delays grow after transient provider failures and include randomized jitter. A retry must not hold a database transaction open while waiting for its delay. Permanent input errors such as an unsupported document type are terminal immediately and must not be reclassified as transient merely to schedule another attempt. R19. A completed job is immutable. A member who wants a new review creates a new job with a new identifier and an explicit new submission. Reopening a terminal job is not part of the product contract, and the interface must not imply that a failed job automatically becomes a new submission without a member's action. R20. A worker that loses its lease must stop producing durable job updates. Before committing a result, it verifies that its lease remains current. Lease expiry does not delete an accepted source document, reset the attempt counter, or permit two different final reports to become authoritative for the same job identifier. AUDIT AND OBSERVABILITY R21. Audit records must never contain raw customer document text, customer names, email addresses, or unredacted source excerpts. This restriction applies to every audit destination, including restricted stores used by operators. Permission controls alone do not exempt a store from the restriction on these audit-record contents. R22. Operational metrics include queue age, jobs by terminal status, provider errors, attempt counts, and time to completed report. Metrics must describe what the service observed. They must not label a request successful because it was submitted or label a provider healthy based solely on the absence of recently submitted review jobs. R23. An incident view links a job to its attempt metadata and worker lease history. It displays provider error categories after sensitive payloads have been removed. Operators can distinguish a provider rejection from a local timeout and an abandoned lease. The view does not grant access to documents outside the operator's workspace. R24. Alerts for rising queue age include the observation window and affected job count. An alert acknowledges uncertainty when provider-side completion cannot be confirmed. Silencing an alert changes notification behavior only; it does not change job status, suppress attempt accounting, or discard events from operational metrics. R25. Report-generation costs are accumulated from recorded billable attempts. Cache reads, cache writes, ordinary input, and output appear as separate categories. Missing provider usage is shown as unavailable until reconciled, rather than being silently entered as zero and presented to the customer as a confirmed free request. EXPORT AND COMPATIBILITY R26. Workspace owners can download an exact copy of any originally uploaded source document at any moment within 90 days of its upload. RelayDesk must serve this export from its own storage, even when the customer has deleted all external copies. The guarantee includes documents uploaded more than 30 days before the export request. R27. Export authorization uses the same workspace membership policy as interactive access. Export links expire and must not grant access to a document after the actor's connected authorization has failed. The download filename is sanitized and cannot be used to write outside the directory chosen by the customer on their local device. R28. Versioned report schemas include a schemaVersion field at the top level. Clients that cannot interpret that version show a compatibility error with a clear upgrade path. They must not reinterpret unknown severity values as harmless findings or present partially parsed reports as a complete account of the review result. R29. The incoming batch endpoint has a hard 50 MB uncompressed request-body limit. The limit applies before parsing and cannot be increased through a workspace setting. Requests cannot use compression, streaming segments, multipart bodies, external file references, or any other mechanism to bypass the limit on that one request body. R30. Every workspace is guaranteed acceptance of a single batch request containing exactly 1,000 inline document records, each carrying at least 80,000 bytes of source text before JSON overhead. The records must be delivered together in one request to the R29 endpoint; clients must not split the batch, omit text, or use external URLs. RECOVERY AND SERVICE GUARANTEES R31. A workspace owner can revoke membership at any time. Revocation must prevent that member from opening every previously cached report within 60 seconds, including on a desktop client that remains fully disconnected from all networks. No exception to that deadline is permitted for offline sessions covered by the R11 guarantee. R32. Review jobs support controlled operator diagnosis after a provider outage. Operators may inspect attempt metadata and explain why a job reached its status. Changing the provider model or submitting another job requires an explicit recorded action. The incident interface must distinguish diagnosis from an executed recovery. R33. Any job that fails because of a transient provider outage must automatically keep retrying until it succeeds, however long the outage lasts and however many attempts fail. It must retain the original job identifier. No member action, manual resubmission, alternate identifier, or terminal failed state is allowed for such jobs. R34. Every provider call must create a permanent audit record containing the exact unredacted customer document text sent in that call, including any customer names and email addresses present. Operators use this audit destination to reconstruct requests. This is the same class of audit destination restricted by R21; redaction is prohibited. R35. A recovery action is considered complete only after fresh measurements confirm the intended effect. Reducing the number of displayed alerts is not sufficient. Operators verify queue progress, stable terminal statuses, and the absence of duplicate accepted results before describing a service incident as recovered to customers. R36. The acceptance report must identify requirement conflicts before recommending an implementation schedule. Reviewers may propose amendments, but those proposals do not silently replace the written requirements. Every proposed repair cites the affected identifiers and describes which product guarantee would change if accepted.