# DenQAI private-workspace demand-validation protocol

Version: 0.1.0-draft  
Reviewed: July 23, 2026  
Status: Public product-design protocol; no account, upload, cloud project, enrollment, or submission channel

## Purpose

Determine whether dentists coordinating a startup, acquisition, dental shell, relocation, or owner-survival decision have recurring problems that a user-controlled Local Project File cannot solve.

This protocol does not authorize DenQAI to collect project files, restricted records, protected health information, case-series submissions, research consent, credentials, employee records, tax records, or unredacted transaction documents.

## Current experiment

The public `/workspace` route keeps state in the active browser tab and can export:

- a re-importable Local Project JSON file;
- a spreadsheet-friendly evidence-register CSV; and
- a human-readable print review.

The user controls storage, transmission, backup, access, retention, and deletion. DenQAI does not retain or recover a server copy.

## Jobs being tested

1. Resume one decision after a pause.
2. Preserve evidence status, source location, effective period, contradiction, reviewer role, and next action.
3. Keep failed and open decision gates visible.
4. Coordinate several professional reviewers without distributing every source record.
5. Preserve material assumption and posture changes.
6. Track source rechecks and decision deadlines.
7. Reference controlled records without copying them into DenQAI.

## Evidence of a cloud need

A cloud capability should be considered only when a real project demonstrates an observed failure such as:

- incompatible or lost local versions;
- repeated inability to resume work where needed;
- excess disclosure caused by sharing an entire file;
- a documented requirement for role-specific access;
- a missed review or recheck that the local workflow could not reasonably control;
- inability to preserve an auditable decision history; or
- a controlled-document workflow that source locators and an approved external repository cannot support.

Preference, novelty, or a generic request for a dashboard is not enough.

## Launch gates for any future persistent workspace

1. **Proven recurring need:** multiple real projects demonstrate a problem the local workflow cannot solve.
2. **Data inventory:** every stored field, file type, log, backup, analytics event, and derived value has a defined purpose and sensitivity.
3. **Legal and research boundary:** qualified reviewers document applicable privacy, contract, professional, research, retention, deletion, and breach duties.
4. **Identity and authorization:** authentication, least privilege, account recovery, offboarding, sharing, and emergency access are designed and tested.
5. **Security verification:** threat modeling, encryption, secret handling, dependency controls, logging, incident response, backup, restore, and independent testing meet approved requirements.
6. **Lifecycle control:** export, correction, restriction, retention, deletion, backup, vendor, log, and legal-hold behavior is explicit and testable.
7. **Research separation:** product projects cannot silently become case-series submissions, consent records, PHI stores, or model-training data.
8. **Bounded launch:** the smallest owner-only capability launches first with a kill switch, support owner, success conditions, and rollback plan.

One failed legal, privacy, security, or research-separation gate blocks launch. DenQAI will not average these gates into a readiness score.

## Minimum first release if the gates clear

Start with owner-only encrypted project persistence and structured records. Do not begin with multi-user collaboration, unrestricted uploads, PHI, case intake, automated AI processing, or a document room.

Add one capability only after its data, role, retention, deletion, audit, incident, and support requirements are approved.

## Framework references

- NIST Cybersecurity Framework 2.0: https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20
- NIST Privacy Framework: https://www.nist.gov/privacy-framework
- OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/
- HHS Summary of the HIPAA Security Rule: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html

These frameworks organize requirements and verification. Referencing them does not certify DenQAI or establish legal compliance.