Trust & Compliance

Sprint-Ready is not itself a medical device

Sprint-Ready is a requirements-authoring tool. It ingests a client's own source documentation — specifications, process flows, existing backlog items — and drafts candidate development tickets, which the client's own team reviews and manages through their normal software development lifecycle. Sprint-Ready does not ship inside, control, or become part of any client's regulated product. The safety classification and risk-management burden for a client's actual product (IEC 62304, ISO 14971) sits entirely with the client and their own quality processes.

This page exists so a client's own quality or regulatory reviewer can assess Sprint-Ready as a tool used within a regulated process — the same way IEC 62304 asks a team to account for externally-sourced components ("SOUP"), or the way a GAMP-5-style review asks whether a computerized system used in a regulated workflow is trustworthy enough to rely on.

What Sprint-Ready actually does

• A client uploads source documents (PDF, Word, Excel, process-flow diagrams) through the control panel.
• An automated pipeline extracts the text — or, for flowchart images, uses a vision-capable model with a purpose-built extraction prompt.
• An LLM drafts candidate tickets, each with a title, description, acceptance criteria, an explicit list of any data gaps or ambiguities found in the source, a source reference tracing exactly where the requirement came from, and a preliminary hazard/risk indication (see below).
• A semantic deduplication step compares each candidate against the client's live backlog in their chosen project-management tool — Azure DevOps or Jira, both with real logged production executions behind them — in real time, to avoid duplicate work items.
• Based on that comparison, the ticket is posted as a new work item or merged into an existing one, with an explicit audit note.
• Every ticket action is written to a permanent traceability record, independent of the ticket's presence in the PM tool, and can be assembled into a downloadable traceability matrix from the client's own control panel.

Every ticket traces back to its source

Each ticket action is recorded once, holding: the client and seat it belongs to, the pipeline run that produced it, the source filename and section/paragraph reference, the ticket title, whether it was created or merged, the resulting Azure DevOps work item, the matched item and similarity score for a merge, and a timestamp. This record is independent of Azure DevOps itself — even if a work item is later edited or removed there, the record of what was generated, from what source, and when, stays intact.

Clients can view this directly in their own control panel, filterable by document, file type, date range, and (for account admins) by team member — so any ticket in the backlog can be traced back to its exact source in seconds, not by asking us. Those records can also be exported as a single traceability matrix on demand, rather than needing to be collated by hand from individual tickets.

Hazard & risk classification

Every generated ticket now carries a preliminary hazard/risk indication: an AI-assigned severity rating and probability rating, combined into a risk index by a fixed, deterministic calculation running in our own code — the risk score itself is never computed by, or trusted from, the language model. An unrecognised or malformed model output fails safe to an explicit “unclassified” state rather than being coerced into a plausible-looking band.

This is deliberately labelled as preliminary and non-certified everywhere it appears — on the work item itself and in every place we describe it. ISO 14971 does not mandate a single universal severity/probability scale; each organisation defines its own in its own Risk Management Plan (§4.4). What we ship is a sensible, fixed default scale to save your team the blank-page problem, not a substitute for your own risk-management process. Treat it exactly as you would any other AI-drafted input: a starting point for a qualified person on your team to review, adjust, and formally classify.

Change control and testing

We don't consider a feature "done" when the code is written — we consider it done when it has been proven against something real. That standard is applied consistently, and it's worth describing in more detail than most vendors will, without handing over the implementation itself.

What's tested, how, and when — capability by capability

Every capability below is described the same way: what it does, how we verified it, and the most recent evidence for that verification. Where we have a real execution ID, work item number, or dated event, we cite it rather than say "tested" and leave it there.

Core pipeline

• Document ingestion (Word, Excel). Live in production. Most recently proven 2026-09-09: a .docx specification was ingested end-to-end and generated 8 real Azure DevOps work items (#1535–#1542) in a single run.
• Ticket generation on AWS Bedrock. Live in production, running Anthropic's Claude model hosted on Bedrock. Proven repeatedly by logged executions with real, itemised token cost — for example execution #10914 on 2026-09-07, which generated 3 complete tickets for a measured cost of £0.024411.
• Dedup Guard (semantic deduplication). Live in production. Verified against a real, live backlog, not a synthetic one — execution #10914 compared 3 new candidate tickets against 770 real Azure DevOps backlog items fetched at runtime, with zero fetch errors and correct novel/duplicate classification on all three.
• Azure DevOps create & merge routing. Create is the most heavily exercised path: 11 real work items created across two September 2026 production runs (#1532–#1534, then #1535–#1542). The merge/update path was fixed and database-verified on 2026-09-03; it simply hasn't been the path a matching backlog item triggered in the most recent runs, so we describe create as the more recently proven of the two.
• Jira create & traceability routing. Live in production, proven end-to-end on 2026-09-14: 13 real Jira issues created via Jira's Cloud REST API across two production runs (SCRUM-5–SCRUM-12, then SCRUM-13–SCRUM-17), each with its traceability record correctly written — including a real, Jira-specific traceability-logging defect found and fixed the same day, then proven fixed by the second run. Run against an internal test Jira project rather than a live paying customer's account so far; it's the same code path a client's own Jira account uses, and we'll note here the day a live client account is the one behind the numbers.
• Hazard & risk classification. Live in production since 2026-09-08, deployed and verified 2026-09-09: all 8 tickets from that run's smoke test carried populated hazard fields, severities ranging 4–9, correctly banded LOW/MINOR/MODERATE. Deterministic, code-computed scoring — see the dedicated section above for the ISO 14971 framing.
• Traceability matrix export. Deployed and verified 2026-09-09. Pre-deployment self-testing caught and fixed three real defects before they reached production (a route-anchor mismatch, a template-indentation issue, and a CSV filename-escaping bug that would otherwise have thrown a runtime error). The live export route was then smoke-tested and confirmed correctly access-gated rather than erroring.

Knowledge base (RAG)

• Ingestion & embedding. Live in production since 2026-09-03. Source documents are chunked and embedded using Amazon Bedrock's Titan Text Embeddings model (1024-dimension vectors), stored in our own database, scoped by client. First real run scored a 1.0 retrieval match on a direct query test.
• Retrieval into ticket generation. Live in production, with an honest history: wiring retrieval into the generation prompt initially introduced a real defect (a missing header on the embedding-query call broke every pipeline execution that reached the LLM step). Found and fixed 2026-09-07, then proven fixed the same day by execution #10914 running the full pipeline successfully end-to-end — the first time retrieved context was ever populated from real, non-empty data, with every generated ticket's source citation correctly pointing only to the current document, never to retrieved background context.
• Per-seat knowledge-base permissions. Deployed 2026-09-07. View/upload/delete are three independent toggles a client administrator sets per seat, enforced server-side — not just hidden in the interface — with soft-delete preserving the audit trail rather than destroying it.

Account & platform security

• Two-factor authentication. Deployed 2026-09-07: TOTP with QR-code enrolment and eight one-time backup codes, session-locked after five failed attempts. Verified live post-deployment. Available to every account, opt-in rather than enforced today.
• Login & session hardening. Deployed 2026-09-07: an open-redirect vulnerability closed, failed-login lockout with full audit logging, and session cookies hardened (HTTPS-only, HttpOnly, SameSite, 12-hour lifetime).
• Tenant isolation. Verified by direct, line-by-line review of the highest-risk request-handling code. Isolation is enforced entirely in application code against a server-derived session identity — there's no separate database-level isolation layer yet, which is normal for our current scale and stated here rather than assumed away.

Inbound automation

• Payment webhooks (Stripe). Signature-verified before processing. Tested end-to-end in Stripe's test mode: a real Checkout session, a real verified webhook, and a real auto-generated invoice marked Paid.
• Delivery & suppression webhooks (AWS SES/SNS). Signature-verified against AWS's own signing certificate, with the fetch restricted to AWS's own domains. Genuinely tested end-to-end on 2026-09-09 using AWS's real mailbox-simulator addresses: a real send produced a real bounce, a real SNS notification, a verified webhook call, a suppression-list write, and a confirmed block on a subsequent send to that address.

What's still being proven

We only call a capability "live" once it has cleared a real execution against a real external system — not once the code is complete. These two haven't cleared that bar yet, and here is exactly why, in full, rather than a one-line disclaimer.

Data security and tenant isolation

Every client's data — documents, generated tickets, traceability records, accounts — is logically separated by client and, within a client, by individual user seat. That separation is enforced in application code on every single request, derived server-side from a cryptographically-signed session token established at login — never from a client ID, seat ID, or any other identifier a browser could supply in a URL, form field, or header. In practical terms: there is no request path in the product where changing a value in your browser could show you another client's documents, tickets, or traceability records.

Knowledge-base documents used to ground ticket generation carry their own, finer-grained permission model: a client administrator explicitly grants each individual seat the ability to view, upload, and/or delete knowledge documents — independently of one another — and a seat with no granted permission sees nothing. Deleting a document is a reversible soft-delete: it stops influencing new ticket generation immediately, but the record and its history are retained and restorable rather than destroyed outright, so an audit trail is never lost to an accidental — or malicious — deletion. A client can never promote their own document into a shared/global library visible to other clients; that boundary is enforced platform-side, by design, not left to configuration.

What happens to a raw source upload. A document you submit moves through the pipeline — ingested, processed, marked complete — and the tickets, source citations and traceability record it produces are retained by design, indefinitely, because that record is the audit trail your own quality process relies on. We do not currently publish a fixed deletion SLA for the raw uploaded file itself once processing completes, and we'd rather say that plainly than imply one exists. If a specific retention or deletion commitment for source files is something your procurement or data processing agreement requires, contact us and we'll agree one in writing rather than leave it implied.

Every authentication event, permission change, and administrative action is written to an append-only audit log, independent of the traceability records described above, so account-level activity is reviewable in its own right.

AWS Bedrock and Claude: what happens to your content

Sprint-Ready's document-processing and ticket-generation pipeline runs on Amazon Bedrock, using Anthropic's Claude models hosted inside AWS's own infrastructure boundary. Two independent sets of published terms govern what happens to a client's content once it reaches this step, and we think it's more useful to cite both directly than to summarize them for you.

AWS's position. Per AWS's own Bedrock documentation, customer content is not shared with the underlying model provider for the provider's own purposes, and Amazon Bedrock does not use customer inputs or outputs to train or improve the underlying foundation models. Any temporary retention on AWS's side is narrowly scoped and time-bounded, tied to safety and abuse-prevention review rather than model training. Full detail is in AWS's own Bedrock data retention documentation, its Security, Compliance & Privacy page, and its Model Training & Privacy page — linked in Sources below.

Anthropic's position. Separately, Anthropic's Commercial Terms of Service — which govern the Claude API and any product built on it, including Sprint-Ready's use via Bedrock — state that Anthropic does not use inputs and outputs submitted through commercial or API channels to train its models by default. This is explicitly distinct from Anthropic's consumer Claude.ai chat product, where a 2025 policy change introduced default training-data use for consumer chats unless a user opts out; that change does not extend to commercial or API-based products, which is exactly what Sprint-Ready uses.

Who's actually responsible for retention, on Bedrock specifically. When Claude is accessed through Amazon Bedrock rather than Anthropic's own API, AWS — not Anthropic — is the data processor, and it's AWS's own retention and compliance controls that govern your content at that layer; Anthropic's separate no-training commitment for commercial/API use still applies to the model itself. Neither party's policy amounts to instantaneous deletion the moment a response is returned — retention is bounded and narrowly scoped to safety/abuse review, not open-ended and not for training, and we'd rather describe it that way precisely than round it up to a stronger claim than either company's own documentation supports.

Scope, stated plainly. Word and Excel document ingestion, and the retrieval-augmented context step, are confirmed running on Bedrock through real production executions. The PDF and image/flowchart-ingestion paths target the same Bedrock-hosted endpoint but have not yet had a dedicated, logged end-to-end verification pass since the migration to Bedrock — noted here rather than assumed to be identical.

The human-review model

A ticket lands in a client's Azure DevOps backlog once it clears the deduplication check. From there, it is subject to the same backlog grooming, sprint planning, and story-pointing process a client's team already applies to any backlog item — nothing is implemented against it without a person on the client's team looking at it first, exactly as with any other item in the backlog.

Our recommendation to every client is explicit: treat a Sprint-Ready-generated ticket with the same review any AI-drafted or externally-sourced requirement deserves before implementation begins. Tickets can be filtered and reviewed by document, date, and author entirely from within your own control panel before your team picks them up.

Cited directly, not summarized from memory

• AWS — Amazon Bedrock: Data retention
• AWS — Amazon Bedrock Security, Compliance & Privacy
• AWS — Amazon Bedrock Model Training & Privacy
• Anthropic — Commercial Terms of Service
• Anthropic Privacy Center — Is my data used for model training?
• Anthropic Claude Platform Docs — API and data retention
• Anthropic — Updates to Consumer Terms and Privacy Policy