RFC · designed in the open — issues + ideas welcome

Open knowledge packages for agents.

Like npm — but for knowledge, not code. The knowledge an AI agent needs — a method, a team's conventions, a domain primer — vendored into your repo as plain files, read with the agent's strongest tools: grep, read, glob.

Code has git, then npm. Knowledge has no git — so Pinakes is the npm without one: a thin open envelope around free content, vendored where agents already grep.

agent shell
$ pin add github:acme/team-handbook
 vendored 4 files → ./knowledge/team-handbook/  (provenance verified)
$ grep -ri "deploy on friday" knowledge/
knowledge/team-handbook/conventions.md:  Never deploy on Friday. See incident #44.

One grep — and the agent cross-references the team's rule against your actual code. No server round-trip. Offline. Diffable.

Why local beats remote

Context7 and RAG keep knowledge remote. Pinakes makes it native.

A remote lookup is one chunk per call, fetched on demand, never part of the agent's working set. Vendored knowledge sits in the repo — so the agent reasons over it the same way it reasons over your code.

Remote Context7 · RAG

  • Lives behind a server — one lookup, one chunk per call
  • Never enters the agent's working set or its grep
  • Can't be diffed against your code or reviewed as a PR
  • Online-only; opaque about what version answered

Local Pinakes

  • Vendored into your repo as plain Markdown files
  • Cross-referenced against real code in a single grep
  • Offline, diffable, reviewable as a pull request
  • Versioned & provenance-signed — you see its source

There is no universal substrate for knowledge the way git is for code — knowledge is irreducibly multi-representational (prose, graph, table). So Pinakes standardizes only a thin envelope — manifest, versioning, provenance — and leaves the content free.

How it works

Four commands. Plain files where agents already look.

Track knowledge packages like dependencies — add, update, verify — and they land as Markdown in ./knowledge/.

~ the CLI (preview)

pin
$ pin add github:acme/team-decisions   # vendor straight from git
$ pin add team-decisions               # …or by name, via the registry
$ pin update                           # keep tracked packages current
$ pin verify                           # check provenance + integrity

~ what lands in your repo

your-repo/
your-repo/
├─ src/
├─ knowledge/
│  ├─ team-decisions/
│  │  ├─ pinakes.json     # the envelope
│  │  ├─ conventions.md
│  │  └─ decisions.md
│  └─ domain-primer/
│     └─ glossary.md
└─ package.json

An open standard — not a product

Substrate-independent. Apache-2.0. No gatekeeper.

Pinakes is a format, openly licensed. Publish a package from anywhere:

a bare Markdown folder a git repo a NoeBase Space

NoeBase is the first reference host — never the gatekeeper. The envelope belongs to everyone who implements it.

Status

Early — RFC stage. Being designed in the open.

The envelope is real but not frozen. These are the open questions on the table right now — disagreement is welcome:

Unit taxonomy — what counts as a package Versioning semantics — what a bump means for prose Provenance & signing — trust without a registry Registry resolution — name → source