Submitting a pack

A knowledge pack is a folder of Markdown files — each file is one article, compiled from curated sources by a top-tier language model. Once submitted, it enters a community review queue before being included in the registry and made available to every node on the network.

This page walks through the full process: building the pack, structuring the repository, filling in the submission form, and what happens after you submit.

For a reference on the pack format itself, see Knowledge packs.

Building your pack

OCC does not mandate a specific tool, but Forge is the recommended path. Forge handles source ingestion, chunking, and compilation in a single pipeline — you provide the sources, it produces the wiki files. You can also build a pack manually if you have an existing pipeline or prefer full control over the output.

Whichever method you use, the content guidelines are the same. Andrej Karpathy's essay on knowledge distillation is the canonical reference for how a well-structured knowledge article should read:

karpathy/wikify — GitHub Gist

The core idea: each article should read like a dense, factual Wikipedia entry — structured, well-referenced, exhaustive on its topic. Avoid conversational prose, hedging, and filler.

Source selection

Good sources produce a good pack. A pack is only as reliable as what it was compiled from.

• Preferred sources: Wikipedia articles, academic papers, official documentation, authoritative reference books, primary sources.
• Avoid: opinion pieces, aggregator blogs, paywalled content you cannot verify, sources with factual disputes.
• Diversity: cover the topic from multiple independent sources. A pack built from a single source will have the gaps of that source.

If you use Forge, sources can be provided as URLs, local files, or free text. Every source you use will appear in the manifest and is visible to reviewers.

Repository structure

Your pack must live in a public GitHub repository. The structure is strict:

your-pack-repo/
├── wiki/
│   ├── introduction.md
│   ├── topic-one.md
│   ├── topic-two.md
│   └── ...
└── manifest.yaml

The wiki/ folder must be at the root of the repository. All content files must be inside it. The manifest.yaml must also be at the root.

The manifest

Every pack must include a manifest.yaml at the repository root. It is a minimal record of identity and provenance:

name: caesar
version: 1.0.0
domains:
  - history
  - rome
language: en
sources:
  - url: https://en.wikipedia.org/wiki/Julius_Caesar
    fetched: '2026-05-10'
    hash: 6f8cb28a83cad4b05edead944b1742527466733170923d84298a0888a722ac54
signature: null
min_node_version: 0.1.0

Each ingested source contributes one entry under sources, with the URL, the date it was fetched, and a content hash that lets a reviewer verify the pack was built from the source they expect.

The signature field is reserved for cryptographic signing, which will be rolled out in a future release (see Roadmap). Set it to null for now.

min_node_version declares the minimum OCC Node version required to ingest this pack. Use 0.1.0 unless you have a specific reason to require a later version.

Filling in the submission form

Pack name — The human-readable name of the knowledge domain. Use title case. This is what users see in the registry. Example: Julius Caesar.

Slug — A permanent, URL-safe identifier. Lowercase letters, numbers, and hyphens only. Cannot be changed after submission. Example: julius-caesar.

Short description — One or two sentences describing what the pack covers. Max 200 characters. This appears on the pack card in the registry.

Full description — Optional. Use this to explain your source selection, methodology, and any caveats. Reviewers will read this.

Version — Semantic version of the pack. Default is 0.1.0. The patch number increments automatically when an approved change request is merged.

Wiki page count — Number of .md files inside your wiki/ folder.

AI model used — The exact model identifier you used to compile the pack. Must be a top-tier model. The current recommended list is in Forge's model selector.

Built with Forge? — Whether you used OCC Forge to generate the pack. Affects how reviewers evaluate the methodology.

GitHub repository URL — The full URL of your public repository. Example: https://github.com/yourname/julius-caesar-pack. The repository must be public and follow the structure described above.

GitHub discussion URL / Review thread URL — Optional links to any public discussion or review thread you have already opened. Not required at submission.

After submission

Once submitted, your pack enters the review queue with status CANDIDATE.

1. Community voting — Any logged-in user can cast an up or down vote. Votes are visible and contribute to the pack's reputation signal.

2. Formal review — Users with the Pack Creator role or above can write a structured review: Approve, Request Changes, or Reject. Reviewers check source quality, content accuracy, model tier, pack structure, and manifest correctness.

3. Status progression — A Registry Steward evaluates the formal reviews and moves the pack through the status machine:

   • CANDIDATE → UNDER_REVIEW (when review begins)
   • UNDER_REVIEW → CHANGES_REQUESTED (if issues are found)
   • CHANGES_REQUESTED → UNDER_REVIEW (after you address the feedback)
   • UNDER_REVIEW → APPROVED (when the pack meets the standard)

4. Registry inclusion — An approved pack is available to all nodes on the network. It will appear in the registry and can be ingested by any OCC Node.

Once approved, the pack is not locked. Anyone can propose a change request — to add sources, correct errors, or request deprecation. Accepted change requests increment the patch version.