# Personal Context Blueprint

> Agent-facing counterpart to the [interactive Context Blueprint Lab](/lab/context-blueprint/).

## Purpose

Personal Context Blueprint is a structured course followed by a practical
capstone.
It helps a person understand, design, and download a private-by-default,
agent-readable context repository. It translates the architecture behind
Josiah Wilson's working personal context system into a generic guide and
starter that contain no records from his private repository.

The tool is not an AI memory service, a hosted database, a personality test, or
an invitation to archive everything about a person. It creates ordinary
Markdown files the visitor owns and can revise.

## Course experience

The human page uses a certificate-course-style lesson player rather than a
continuous article. It includes:

- A three-module syllabus with six sequential lessons.
- A focused, one-lesson-at-a-time reading surface.
- A stated learning objective, worked example, and one-question knowledge check
  in every lesson.
- Back, continue, resume, reset, locked, completed, and active states.
- Device-local progress and a final course-completion state.
- A capstone that unlocks after all six knowledge checks are completed.
- A “Skip to tool” action that unlocks the capstone without marking any lesson
  complete; the course remains available and its recorded progress remains
  accurate.

The six lessons teach these architectural decisions:

1. Begin with downstream utility rather than an ambition to store a biography.
2. Give every agent a short `llms.txt` front door and load context progressively.
3. Separate raw capture and imports from maintained knowledge.
4. Make consequential claims inspectable through privacy, source, confidence,
   freshness, and review metadata.
5. Use corrective questions and readable diffs to keep the agent's model from
   drifting.
6. Extend the repository through purpose-built modules, lookup surfaces, and
   carefully gated automation.

Course completion state is optional and stored only in the visitor's browser.
The knowledge checks are instructional checkpoints, not an assessment of
professional competence.

## Capstone workflow

1. Choose the real work the repository should support, such as continuity
   across agents, active projects, decisions, sources, relationships, or
   sensitive domains.
2. Choose context modules. The default structure separates ongoing areas,
   projects, dated events, and outside sources.
3. Choose a review model, default privacy posture, and maintenance safeguards.
4. Inspect the generated repository tree and individual file contents.
5. Download a ZIP containing the starter files or copy a short setup prompt for
   an AI agent.
6. Optionally download an informal local completion record. A visitor may type
   a name for that file; the name is used only in the browser and is not
   submitted or stored by the site. The record explicitly says it is not an
   accredited credential.

## Generated repository contract

Every download includes:

- `llms.txt` as the short agent boot path and repository map.
- `AGENTS.md` as the operational rules for reading and maintaining context.
- `README.md` as the human explanation and setup path.
- `BLUEPRINT.md` as a record of the visitor's architectural choices.
- `EXTENDING.md` as a durable recipe for new modules, lookup surfaces, and
  later automation.
- `inbox.md` as an uncompiled capture queue.
- `constraints/active.md` for current rules that override older context.
- `_templates/entry.md` and `_templates/module-index.md` for future additions.
- `log.md` as a maintenance ledger.
- One `INDEX.md` for each selected context module.
- Optional clearly synthetic examples and a separated `_imports/` lane.

The generated repository uses a progressive-disclosure rule: read
`llms.txt` first, then open only the files relevant to the current task.

## Methodology

The design centers two feedback loops:

1. Downstream utility makes honest context structurally valuable. Incorrect or
   performative context produces worse decisions and project support.
2. Bidirectional question-asking corrects drift. Agents return questions about
   uncertainty, staleness, and contradiction instead of merely producing
   plausible summaries.

Other defaults include human-readable Markdown, visible version history,
privacy tiers, provenance, confidence, freshness, raw-versus-compiled
separation, and a human review step for durable changes.

## Privacy and data flow

- The builder runs entirely in the visitor's browser.
- Configuration choices are not submitted to Josiah's site.
- The tool does not ask visitors to upload documents.
- No account, model call, server-side record, cookie, or analytics event is
  required by the tool.
- The ZIP is assembled locally and downloaded directly by the browser.
- The optional completion record is assembled locally as a printable HTML file.
- Examples are synthetic and contain no records from Josiah's repository.
- Selecting a sensitive-domain module does not make a repository secure by
  itself. Files still require appropriate device, account, encryption, sharing,
  backup, and access controls.

## Current routes

- Human tool: /lab/context-blueprint/
- This specification: /lab/context-blueprint/llm/
- Project article: /projects/personal-context-infrastructure/
- Project agent record: /projects/personal-context-infrastructure/llm/
- Lab index: /lab/
- Agent Lab index: /lab/llm/

## Action surface

There is no server API. The human interface exposes a client-side export action
that creates a ZIP in the visitor's browser. Agents can reproduce the generated
contract from this specification, but should not claim access to a visitor's
configuration or downloaded files.