Loading workspace…
signed outSign in
Every requirement in bioskepsis-insights-user-requirements-v1.1.md, with the verdict the document’s own rules force. No requirement now carries the verdict BLOCKED. Each row carries both halves of its account, what is buildable and what is still held, and names the decisions that released it. A requirement answered the other way is DROPPED, and that is the one verdict nobody can go and change.
Showing the 5 requirements that OQ-47 released. A requirement that the document alone would have held is here because a decision with a date let it through.
| ID | Verdict | Basis | What that means |
|---|---|---|---|
NEVER-06 | BUILD | research | All of it, confirmed by OQ-47: patient data EFEVRE processes on behalf of a hospital never reaches this product or the signal layer. EFEVRE is a processor for that data and a controller only for the consented signal layer, and Article 28(10) is the reason the distinction has teeth: a processor that sets its own purposes becomes a controller. Still held. Nothing. Released by OQ-47. |
XFER-07 | BUILD | inference | All of it, confirmed by OQ-39 and OQ-47. OncoSkepsis runs in EFEVRE's cloud under the institutional licence, and clinicians enter only structured fields, so no patient details reach it. EFEVRE is a processor for that clinical use and a controller only for the signal layer, which is where the institution boundary sits. Still held. Nothing. The boundary is a legal shape the architecture has to match: separate stores, separate access control, a processor contract per hospital and a consent record per clinician. |
XFER-13 | BUILD | inference | All of it, confirmed on 18/09/2026, and it is the load-bearing one. The signal layer delivers to this product through a one-way interface, and this product's services have no read access to the stored coded OncoSkepsis signals. ADR 0002 records the shape that implements it: a signal service that neither product owns, which OncoSkepsis writes to and this product reads from, holding no credential for any clinical store. Still held. Nothing. Until the confirmation this was an inference the architecture already relied on, which is the uncomfortable kind: a design resting on a requirement nobody had agreed. Released by the confirmation of 18/09/2026, OQ-47. |
XFER-15 | BUILD | research | All of it, and it is a prohibition rather than a feature: patient data EFEVRE processes for a hospital is never used for this product or for the signal layer. OQ-47 gives it its legal footing, since a processor that sets its own purposes becomes a controller for that processing. Still held. Nothing. The architecture is what enforces it: this product cannot reach a clinical store, and the boundary refuses at startup a configuration that would let it try. Released by OQ-47. |
DATA-02 | BUILD | stated | All of it, and the answer makes the architecture explicit rather than only the rule. The separation stays enforced by construction: separate stores, separate services, a startup check that refuses a clinical or research database URL or role, and a per- request refusal of a clinical service account. What OQ-05 settles is the individual- level question that used to hold half of this: nothing individual crosses. A pharma user meets an anonymous card, the link between card and person stays inside the signal layer, and no service outside it may read that link. An identity is revealed only by the expert's own acceptance of a contact request (OQ-42), which is a consent record rather than a data flow. Still held. Nothing. OQ-47 adds the legal shape the architecture has to match: EFEVRE is a processor for each hospital's clinical use and a controller only for the signal layer, so the two stores stay separate with separate access control, per hospital contracts and per clinician consent. |