onefrontieronefrontier.ai

docs · catalog

package/catalog/README.mdrendered from source at build

The catalog

catalog/ — the kit's knowledge base

Four files the Rust CLI (package/cli/) reads and every agent keeps current. The LAUNCH surface — filters, create bodies, env channels — lives in ../launch/snipe-params.yaml; a profile row there is the executable form of a row here. The YAML field names are frozen (the CLI's serde structs parse exactly them): rename nothing, add rows.

  • models.yaml — every model: quant, checkpoint size, the known-good engines (image, version, the measured flag set verbatim), draft, min TP per hardware class, traps, launch profile, and any published boot-ready cell image (cell_image: class -> ref, the package/cell/ build).
  • hardware.yaml — every instance class: provider, GPU shape, observed host CPU, the floors a profile gates on, price bands from captures.
  • performance.yaml — one row per measured cell, with its source.
  • rationale_performance-observations.md — the prose case law (hadron annotations, market behavior, the fit-gate proofs). No number lives here and in performance.yaml.

Keeping the catalog current

  1. When a capture or validated file lands, add or extend performance rows. A new cell — a snapshots/<dir>/ corpus capture, a ~/ai/validated/*.md bench file, a preserved drain harvest — earns a row the moment its numbers exist. Extend the existing row when the same model/hardware/engine shape is re-measured.
  2. Numbers only from captures. Never estimate, never fill a slot from recollection, never copy a number that has no capture behind it — an unmeasured slot is null and names the bench still owed. A live gauge sample is a capture (cite it as one); a vibe is not.
  3. Join keys first. A performance row's model must exist in models.yaml and its hardware in hardware.yaml before the row may cite them — add the model or hardware row first, then the performance row.
  4. The profile law. A snipe-params profile is a catalog row's executable form — facts never live in both. The catalog documents why, the params execute how; a value that must match across the two (checkpoint size, engine flags) has one authoritative home per file and must not drift — change the home, then the mirror, in the same round.
  5. The sanitize law. No house hostnames, ports, brands, or fleet references in any catalog row; served names are user-settable config. Sources cite repo-relative paths (snapshots/<dir>/) when the corpus holds the cell; otherwise the preserved evidence path — a validated file, a drain harvest — as-is.