Purpose-Built Projects

A Project works best when it serves one evidence domain: a codebase, product manual, operations runbook set, support corpus, or research collection. Narrow scope produces clearer retrieval, permissions, freshness, and ownership than a single organization-wide dump.

Design Rules

1. Name the decisions or tasks the Project should support.
2. Include authoritative source material and preserve provenance.
3. Exclude generated files, secrets, drafts, and unrelated repositories.
4. Give extraction and linking models enough capability to create useful pages.
5. Evaluate deterministic results and exact excerpts in Explore.
6. Expand scope only when observed evidence gaps justify it.

Explore has no model setting. Models configured for extract, link, and lint affect how knowledge is built and maintained, not query ranking.

projects:
  product-docs:
    schema:
      categories: [concepts, guides, reference, troubleshooting]
    agents:
      extract:
        provider: openai
        model: gpt-5.6-terra
      link:
        provider: openai
        model: gpt-5.6-terra
    watchers:
      docs-repo:
        type: git
        repo: https://github.com/example/product-docs.git
        branch: main
        files:
          rules:
            - name: published documentation
              include: ["docs/**/*.md", "docs/**/*.mdx"]
              exclude: ["docs/drafts/**", "**/node_modules/**"]

Validate with real retrieval tasks: inspect top results, confirm the judged section is in the excerpt, then open the exact revision. A missing result is a source, ingestion, schema, or ranking gap—not an invitation to invent an answer.