◆OOMPF

Profile format

A profile is native OMP YAML. OOMPF reads it to extract facts; it never rewrites or reinterprets the runtime meaning of these fields. The example below shows the fields OOMPF recognizes. Any field OOMPF does not recognize is preserved and reported as an unknown key for forward compatibility.

name: atlas
version: "1.4.0"

modelRoles:
  primary: anthropic/claude-opus
  helper: openai/gpt-4o-mini

retry:
  fallbackChains:
    primary:
      - anthropic/claude-opus
      - openai/gpt-4o

advisor:
  enabled: true

hooks:
  - lint-guard

extensions:
  - repo-context

# Optional OOMPF metadata block (ignored by the OMP runtime)
oompf:
  summary: "A low-cost coding profile for Kimi and GLM."
  kind: coding
  tags:
    - kimi
    - low-cost

Fields OOMPF extracts

  • name, version, and other recognized scalar identity fields.
  • modelRoles — split into role/model assignments; single models and fallback lists are separated.
  • retry.fallbackChains — ordered fallback lists per role.
  • advisor — observed advisor settings.
  • hooks, extensions — collected names.
  • Model selectors anywhere in the document — collected into models, with providers inferred from the <provider>/<model> prefix.
  • Values beginning with @ (for example @tiny) — classified as aliases, not concrete models.

The optional oompf block

The oompf key is namespaced and optional. OMP ignores it at runtime, so adding it never changes installation behavior. OOMPF validates and indexes it separately. See Metadata and summaries.

Validation

OOMPF validates the artifact structurally and scans for secrets. It records a valid/invalid verdict plus value-free advisories. Canonical bytes and any secret values are never stored. See Provenance and revisions.