QOwnNotes

1. Overview

Note-taking application that stores notes as plain Markdown files in a folder, with optional Nextcloud integration.

Category: Knowledge & Office.

2. Version and scope assessed

Version assessed: Source commit 21b4d8554828bf77f89be5b25da7a6722ebc7b8f.

4. Principle profile

5. Fundamental requirements

6. Evidence and verification

• E1: QOwnNotes stores notes as plain Markdown files in a user-selected folder and supports exports. (source), confidence high
• E2: Markdown notes can be opened, edited, synchronized, and backed up with ordinary tools and other Markdown applications. (source), confidence high
• E3: The database schema defines tag records with parent_id, noteTagLink records keyed by tag_id, note filename and subfolder path, and trashItem metadata. Tags and their associations therefore have explicit database state beyond Markdown note text. Copying only note files cannot be assumed to preserve this state; no populated database or missing-database reconstruction was tested. (source), confidence medium
• E4: QOwnNotes works offline and keeps notes on the user’s device. (source), confidence high
• E5: The inspected note-removal path asks about backlinks when relevant and checks a user-question result before invoking note.remove(true). Bulk deletion separately warns that selected folders' files and subfolders will be removed. This establishes application-level confirmation branches, not universal prompting under saved dialog preferences or successful local/server trash restoration. (source), confidence medium
• sovereignty: Plain Markdown files and user-selected storage provide strong control and exit. (source), confidence high
• longevity: E3 remains Not Verified for the existing essential-record scope. The methodology requires established E3 before a positive Longevity finding, so the earlier positive rating is withdrawn pending recovery evidence; source/format strengths are retained as facts, not graded as a failure. (source), confidence medium
• locality: The core note workflow is local and offline. (source), confidence high
• transparency: E5 remains Not Verified. The methodology's Partially meets threshold requires demonstrated minimum oversight, so the earlier positive Transparency and Control finding is withdrawn rather than retained on the strength of one documented control. This is Not assessed, not Does not meet. (source), confidence medium
• E3: The retained schema places hierarchical tags, note-tag associations and trash metadata outside Markdown prose. A populated database/native-folder recovery and relationship reconstruction have not been demonstrated. This is an incomplete essential-record preservation check, not a reason to infer a failure or promote the invalid partial value. (source), confidence medium
• E5: The retained note-removal implementation has backlink and bulk-folder confirmation branches, but saved dialog preferences, local/server trash restoration, other deletion modes and concurrent edits remain unverified. This closes a control-implementation question without establishing risk-appropriate authorization and correction for the whole assessed workflow. (source), confidence medium

7. Migration and recovery

Native storage format: Markdown files in a user-chosen folder.

Synchronization or runtime model: Local folder with optional Nextcloud or ownCloud sync.

Example export or inspection command (not verified against any particular version or data set): grep -rl "keyword" ~/Notes

8. Architectural strengths

Established strengths and their scope are recorded in the evidence and assessment findings on this page.

9. Architectural limitations

• Tag/trash associations have database state that is not demonstrated recoverable from note text alone.
• Confirmation code is present, but effective settings and recoverability remain untested.

10. Assessment findings and remaining work

Evidence update: 23 October 2026

• Resolved: The database schema defines tag records with parent_id, noteTagLink records keyed by tag_id, note filename and subfolder path, and trashItem metadata. Tags and their associations therefore have explicit database state beyond Markdown note text. Copying only note files cannot be assumed to preserve this state; no populated database or missing-database reconstruction was tested. Source.
• Resolved: The inspected note-removal path asks about backlinks when relevant and checks a user-question result before invoking note.remove(true). Bulk deletion separately warns that selected folders’ files and subfolders will be removed. This establishes application-level confirmation branches, not universal prompting under saved dialog preferences or successful local/server trash restoration. Source.
• Open: A complete notes.sqlite/native-folder move and tag reconstruction, Markdown export loss, actual trash recovery and deletion modes, simultaneous edits, network settings and older versions.

Assessment follow-up: E3/E5 and their associated principle findings are now reconciled in rating batch 1 below. Earlier source/fixture observations remain valid within their stated scope; they are not themselves blanket Pass decisions.

Human-readable criteria: Can a person preserve content, structure, links, metadata, and history in an independently readable form, then restore and edit it without a vendor account?

Rating reconciliation: 23 October 2026

Scope: The existing source-pinned application scope; no new application execution. Individual-custodian perspective. The existing broad preservation/workflow scope is retained, rather than narrowed to the one successfully inspected source path.

E3: The retained schema places hierarchical tags, note-tag associations and trash metadata outside Markdown prose. A populated database/native-folder recovery and relationship reconstruction have not been demonstrated. This is an incomplete essential-record preservation check, not a reason to infer a failure or promote the invalid partial value.

E5: The retained note-removal implementation has backlink and bulk-folder confirmation branches, but saved dialog preferences, local/server trash restoration, other deletion modes and concurrent edits remain unverified. This closes a control-implementation question without establishing risk-appropriate authorization and correction for the whole assessed workflow.

longevity: E3 remains Not Verified for the existing essential-record scope. The methodology requires established E3 before a positive Longevity finding, so the earlier positive rating is withdrawn pending recovery evidence; source/format strengths are retained as facts, not graded as a failure.

transparency: E5 remains Not Verified. The methodology’s Partially meets threshold requires demonstrated minimum oversight, so the earlier positive Transparency and Control finding is withdrawn rather than retained on the strength of one documented control. This is Not assessed, not Does not meet.

Evidence record: evidence/rating-reconciliation/batch-1/README.md and runtime-results.json. No target software was installed. Source inspections remain source inspections; no application-level recovery or destructive action was executed.

Remaining work: The existing open recovery and consequential-action scenarios remain pending; the individually explained E3/E5 blockers above determine the current Not Verified and Not assessed findings.

Rating reconciliation batch 1: E3 Not Verified; E5 Not Verified. Longevity Not assessed; Transparency and Control Not assessed. See the declared scope and reasons below; earlier bounded evidence findings remain recorded. The assessment procedure is described in the methodology.