Can a user close the tab, resume from a local file, and understand what changed without an account?
Workspace demand-validation wave · Local only
Prove the coordination problem before storing the project.
The Local Project File brings the decision boundary, evidence register, separate safety checks, reviewer roles, and unmet workspace needs into one portable record. It creates no account, uploads no document, and saves no server copy.
Current persistenceUser-controlled local JSON and CSV only
Accounts, uploads, or collaborationNot offered
Purpose of this waveObserve which local workflows fail before choosing cloud scope
What this wave tests
Four questions—not a feature wishlist.
Does sharing one portable record create real version, disclosure, assignment, or review failures?
Do different advisors genuinely need different access, or can redacted exports and source locators solve the work?
Is the value of persistence large enough to justify identity, authorization, retention, deletion, audit, incident, and vendor controls?
1 · Decision boundary
Name the decision before coordinating the evidence.
Use a coded project label and broad target window. Keep names, exact dates, source documents, credentials, and restricted records outside this file.
2 · Evidence register
Coordinate the supporting document—not the whole document room.
Each workstream preserves status, source locator, effective period, reviewer role, contradiction, and next action. No completeness score hides an open safety check.
PRJ-E01 · Owner fit
What must ownership accomplish—and what burden would make it unacceptable?
Supporting documentWritten owner and household decision criteria
PRJ-E02 · Market
Is collectible, capturable demand sufficient for the intended patient segment?
Supporting documentLocal capacity census and payer-specific access evidence
PRJ-E03 · Entry mode
Does build, buy, shell, associate-to-owner, delay, or employment best survive the downside?
Supporting documentComparable entry budgets, timelines, runway, and reversal conditions
PRJ-E04 · Transfer
Which production, patients, team capacity, contracts, and operating advantages actually transfer?
Supporting documentTarget records, independent review, contracts, and transition dependencies
PRJ-E05 · Capital
Can practice and household reserves survive the downside and delay cases?
Supporting documentFirst 48 Months, debt terms, guarantees, capital events, and household plan
PRJ-E06 · Authority
Do ownership, licensure, entity, contract, lease, and clinical-authority facts permit the plan?
Supporting documentCurrent law, executed agreements, licenses, permits, and qualified review
PRJ-E07 · Operations
Can the team, payer, site, technology, and management system execute without hidden key-person failure?
Supporting documentRole work samples, access map, payer terms, site records, and transition plan
PRJ-E08 · Reversal
Which verified fact would cause redesign, delay, renegotiation, or exit?
Supporting documentDated decision-changing condition tied to supporting evidence
3 · Decision gates
A failed gate stays visible.
Cleared, failed, open, and not-applicable states remain separate. Waiving a hard stop by implication is not a workflow.
Owner and household fit
The plan violates an explicit owner or household hard stop.
Local demand
Verified local capacity or collectible-demand evidence cannot support the downside case.
Ethics and clinical authority
The structure compromises independent clinical judgment or requires an unacceptable care model.
Legal and contractual authority
Ownership, employment, lease, licensing, entity, payer, or other controlling terms block the plan.
Capital and guarantees
Practice or household reserves breach minimums, or guarantee exposure exceeds the owner’s stated ceiling.
Transferability and price
The target’s repeatable value does not support the price or survives only through unsupported seller dependence.
Team and operating capacity
The practice cannot recruit, retain, cover, or execute the operating model in the required timeframe.
Exit and reversibility
The owner cannot identify a bounded loss, redesign path, or responsible exit if the plan fails.
4 · Workspace demand test
Record the failure before building the feature.
“Cloud capability needed” requires an observed failure in a real workflow. Preference alone does not justify storing sensitive practice-decision data.
Resume on another device
Export, close the tab, and resume later. Record whether the local file was sufficient.
Coordinate multiple reviewers
Run one real review cycle. Record whether sending a whole file created delay, confusion, or excess disclosure.
Restrict access by role
Test whether each advisor should see different evidence, notes, or conclusions.
Preserve version history
Make a material assumption change. Record whether file naming and dated exports preserved the decision trail.
Track deadlines and rechecks
Use the project through one deadline or source-expiration cycle. Record any missed follow-up caused by the local format.
Reference controlled documents
Test whether source locators are enough without copying restricted records into DenQAI.
5 · Export gate
Keep the project portable and inspectable.
Export JSON to resume the full project or CSV for the evidence register. Print produces a human-readable review copy.
Export gate clear
No declared restricted category or obvious direct pattern was detected. This is not a certification that the file is safe or de-identified.
Future cloud gate
Eight conditions must clear before DenQAI stores projects.
These are release gates, not a maturity score. A single failed legal, privacy, security, or research-separation gate blocks launch.
Multiple real projects demonstrate a problem that export, re-import, print, and an approved external file system cannot solve.
Every planned field, document type, metadata element, log, backup, analytics event, and derived value has a named purpose and sensitivity class.
Qualified review resolves applicable privacy, contract, professional, research, retention, deletion, and breach duties before collection.
Roles, least-privilege access, authentication, account recovery, offboarding, sharing, and emergency access are designed and tested.
Threat modeling, encryption, secret handling, dependency controls, logging, incident response, backup, restore, and independent testing meet the approved requirements.
Users can export, correct, restrict, retain, delete, and verify deletion; DenQAI can explain backups, logs, vendors, and legal holds.
Product projects cannot silently become case-series submissions, consent records, PHI stores, or training data.
The smallest owner-only capability launches first with a kill switch, support owner, measurable success conditions, and rollback plan.
Interpretation boundary
Security frameworks organize work; they do not certify this product.
NIST CSF 2.0 provides cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. The NIST Privacy Framework helps organizations identify and manage privacy risk. OWASP ASVS provides requirements and a basis for testing application security controls. They are inputs to an approved requirements and verification program—not badges DenQAI can claim by linking to them.
The HIPAA Security Rule applies to electronic protected health information maintained or transmitted by regulated entities. DenQAI’s current public tools prohibit PHI; any future proposal involving ePHI would require a fact-specific legal, role, contract, risk-analysis, and safeguard determination before collection.