Personal Knowledge System Design Prompt

Design a personal knowledge system from the information below.

Inputs
- Knowledge goals: [Knowledge goals]
- Current tools and note inventory: [Current tools and note inventory]
- Capture sources and content types: [Capture sources and content types]
- Constraints and privacy requirements: [Constraints and privacy requirements]
- Retrieval scenarios: [Retrieval scenarios]
- Review capacity: [Review capacity]
- Success criteria: [Success criteria]

Operating boundaries
- Analyze only the materials supplied in this conversation. You may compare uploaded note samples, folder or tag listings, exports, templates, and usage observations, but do not imply access to note applications, cloud drives, accounts, browsing history, or integrations unless their contents or verified outputs are provided.
- Produce a design and implementation plan, not an executed migration. Do not create, move, delete, publish, synchronize, or reclassify records outside this response.
- Require explicit human approval before any bulk import, deletion, destructive deduplication, permission change, public sharing, automated synchronization, or retention-policy change.
- Treat private journals, credentials, health information, financial records, client material, and third-party personal data as sensitive. Recommend data minimization, appropriate access controls, backups, and redaction. Do not reproduce sensitive note content when metadata or a short sanitized example is sufficient.
- Never describe a system as implemented, migrated, tested, verified, backed up, or approved unless supplied evidence proves that action occurred. Keep proposed, observed, executed, blocked, and unverified states distinct.

Input triage and evidence rules
1. First determine whether the inputs identify at least one knowledge goal, the current storage situation, a realistic retrieval scenario, material constraints, and available review capacity. These are blocking prerequisites for a tailored final design.
2. If a blocking prerequisite is absent or conflicting, ask no more than five focused questions and stop before prescribing a final architecture. Explain why each answer affects the design.
3. If only optional details are absent, continue with a bounded draft. Mark each assumption, explain its likely impact, and provide alternatives where the choice could materially change capture effort, retrieval quality, privacy, portability, or maintenance burden.
4. Classify material statements as supplied fact, observation from supplied artifacts, assumption, recommendation, conflict, or unknown. Do not infer actual habits merely from folder names, templates, or stated intentions.
5. When note samples or inventory data are supplied, cite them by filename, item label, or user-provided identifier. If no inspectable artifacts are supplied, say that the design is based on self-reported context rather than an audited collection.

Design workflow
1. Translate the knowledge goals into concrete jobs such as remembering commitments, developing ideas, supporting projects, preserving sources, preparing writing, or retrieving decisions. For each job, define the triggering situation, desired information, retrieval path, and acceptable time-to-find.
2. Diagnose the current system for capture friction, inbox accumulation, duplicate notes, inconsistent naming, tag sprawl, orphaned notes, broken links, source ambiguity, stale project material, mixed private and shareable content, over-classification, and review debt. Distinguish evidenced problems from plausible risks.
3. Select the smallest architecture that supports the retrieval scenarios. Compare folders, tags, links, search, saved queries, indexes or maps of content, and project or area views. Use methods such as PARA, Zettelkasten, or evergreen notes only where their mechanics solve a stated need; do not adopt a method by brand alone.
4. Define a content model. Specify necessary note types, such as inbox items, source notes, durable concept notes, project notes, decisions, meeting notes, and indexes. For each retained type, state its purpose, minimum metadata, naming convention, lifecycle, link behavior, archive rule, and example. Avoid metadata that has no retrieval or governance function.
5. Define the operating flow from capture through clarification, linking or filing, use, review, archive, and deletion. Include fast capture rules, a processing threshold, duplicate handling, source attribution, task-versus-note separation, and a fallback for items that cannot yet be classified.
6. Design retrieval before optimizing organization. Map each important retrieval scenario to a primary route and a fallback route. Include search vocabulary, filters, links, indexes, dates, project context, or source metadata as appropriate.
7. Set review routines that fit the stated capacity. Separate inbox processing, active-project review, periodic knowledge gardening, link or source maintenance, and archive review. Assign a trigger, time box, input, action, and completion condition to each routine.
8. Evaluate trade-offs explicitly: capture speed versus metadata quality, flexible search versus controlled vocabulary, linking versus folder maintenance, local ownership versus cross-device convenience, automation versus transparency, and comprehensive migration versus gradual adoption.
9. Propose a reversible pilot before broad migration. Use a representative but non-sensitive subset, preserve originals, define backup and export checks, maintain an exception log, and specify rollback steps. Prefer copy-first migration and quarantine over irreversible deletion or merging.
10. Define verification tests and acceptance evidence. If tests have not been run, provide expected observations and mark actual observations as unavailable rather than fabricating results.

Required deliverable
Produce the following sections in order:

1. Input and evidence register
A table with: item, status, classification, source or artifact reference, confidence, conflict or limitation, and design consequence.

2. Knowledge jobs and retrieval requirements
A table with: knowledge job, trigger, target information, primary retrieval path, fallback path, target time-to-find, privacy level, and acceptance condition.

3. Current-state diagnosis
List evidenced pain points separately from unverified risks. For each, provide affected material, likely cause, consequence, and whether it should be fixed now, monitored, or accepted.

4. Recommended system architecture
Describe the proposed tools-neutral structure and, where the supplied tools permit, map it to their actual features. Include containers, note types, metadata schema, naming rules, linking and tagging policy, search or index strategy, archive boundaries, and task-management boundary. Explain rejected alternatives and trade-offs. Do not claim a feature exists unless the supplied materials establish it; label feature assumptions for confirmation.

5. Content model specification
Provide a table with: note type, purpose, creation trigger, required fields, optional fields, naming example, linking rule, review rule, archive or deletion rule, and sensitivity considerations.

6. Capture-to-retrieval operating procedure
Give executable procedures for capture, inbox processing, source attribution, synthesis, linking or filing, retrieval, review, archiving, duplicate resolution, and handling unknown items. Include decision rules rather than vague advice.

7. Review calendar and maintenance budget
Provide daily or event-driven, weekly, monthly, and quarterly routines only where justified. For each, state trigger, maximum duration, inputs, actions, completion signal, and what to defer when capacity is exceeded.

8. Pilot and migration plan
Define scope, sample-selection rationale, prerequisites, backup and export evidence, copy-first steps, mapping rules, duplicate policy, exception log, rollback procedure, human approval gates, and stop conditions. Stop conditions must include missing backups, unexpected data loss, permission exposure, unreadable exports, material record-count discrepancies, or unresolved handling of sensitive content.

9. Verification and acceptance matrix
Include: test, method, expected observation, actual observation, evidence required, status, and remediation. Cover at minimum capture speed, inbox processing, retrieval for each priority scenario, source traceability, duplicate handling, orphan detection, sensitive-content access, export readability, backup recovery sampling, review workload, and rollback. Use not run or unavailable for actual observations without execution evidence.

10. Decision and uncertainty log
Record major decisions, supplied facts, assumptions, unresolved conflicts, unknowns, approval owner, and the consequence of leaving each unresolved.

11. Handoff
State the smallest safe next action, the person who must authorize it, the materials needed, and the evidence that would permit advancement from proposed to pilot-ready or from pilot-ready to accepted.