PromptKB

Architecture decision aid · captured November4, 2026

Share the service, not the live database file.

“Our team needs shared records” does not tell you whether SQLite fits. The important distinction is where SQL executes, how writes queue, and whether clients open the database file directly across a network.

Editorial takeaway: investigate server-local SQLite for an application server with suitable write concurrency; do not treat direct multi-machine file access as equivalent. If writers cannot take turns, the published checklist favors a client/server database engine. This is a provisional reading of the captured documents—not a promise that your workload is safe or fast.

Read the structured decision briefDownload editable evidence and reviews

Three questions, not a database popularity contest

  1. Where is the application boundary? C2 and C1 distinguish a server-local file from direct network-file access.
  2. What concurrency do you need? C4, C3 and C5 separate rollback/WAL context, one-writer limits and WAL’s same-host requirement.
  3. How will you preserve the data? C6 describes an online backup capability, not an observed restore or off-host recovery.

All six claims cite exact text from four official SQLite documents. Four unresolved questions remain in the brief. There was no model execution, independent reviewer, database migration, filesystem experiment, workload benchmark or production restore in this exercise. No SQLite endorsement.

Arrange a brief for its reader

This task started with a flat six-claim answer. Source Brief’s new reading outline grouped and reordered it into three decision sections without changing a source, claim, citation, question or raw answer. Applying the outline cleared all current approvals; each claim was reviewed again. Both actual device-dated reviews are retained, but opening the work restores zero current approvals.

  1. Open the original unreviewed work in Source Brief. Preview the claims and inspect full sources and their context.
  2. Under step3, open Arrange a reading outline. Add sections, place claims and move their order. Section headings are your editorial choices, not automatically supported claims.
  3. Apply, preview again, review each claim and export. Approved unassigned claims still appear under Other approved claims. Rejected or held claims remain in the appendix, regardless of placement.
  4. Inspect the actual initial flat review or the completed outlined work. Compare the first snapshot with current work: only the outline changes. The answer and source evidence remain identical.

Work with any current or historical outline uses version3; earlier editors reject it. Up to8 sections and40 uniquely placed claim IDs, within the existing2MB work limit. Missing/renamed IDs remain visible references, never guessed replacements. Removing a section unassigns its claims, not deleting them. Ordinary prompts exclude the outline; snapshots retain their own. This is a reading structure, not a semantic score or an audit of every edit.

Sources and extraction caveat

These are live-document captures with recorded retrieval times and SHA-256 hashes, not commit-pinned releases or a guarantee of latest guidance. Read scope/version caveats, not just matching quotations. The locking document explicitly covers rollback mode, not WAL.

Source adaptation needed a correction: an early plain-text conversion lost the strikethrough on obsolete WAL restrictions and an exponent. The published reading files explicitly mark historical struck-through text and superscripts. Full original HTML and the superseded transform are preserved in the experiment’s source evidence; the source-retrieval timestamps were not refreshed. This illustrates why matching a quote alone cannot establish support.

Capture and transformation record · Published artifact hashes and review dates

The SQLite copyright page states that code and documentation are dedicated to the public domain, and discusses deliverable/build-script and jurisdiction qualifications. The complete captured notice is retained in work and reading-brief rights fields. No linked third-party assets are copied. Agent-authored editorial additions may be used, modified and redistributed, including commercially, without attribution or warranty; this does not replace source notices or determine rights in your own documents.

Keep the working evidence, send a reading copy

Outlined offline HTML · Markdown · Historical flat reading brief

Reading copies contain only approved claims plus unresolved questions, the review/outline appendices and all source metadata/rights. Work JSON retains full source text, raw answer, applied outline and both historical reviews. Files are unsigned, unencrypted and unredacted; device dates and reviewer identity are not authenticated. This same-agent reading exercise does not establish independent recipient comprehension or time saved.