Facility Knowledge#
The Facility Knowledge system gives the OSPREY agent on-demand access to structured narrative knowledge about your facility — subsystems, device families, operational procedures, physics notes, and references.
It uses a two-altitude model, split by when the agent needs the content:
Always in context — the facility’s core operating context, carried in the Markdown rules under the project’s
.claude/rules/directory. These rule files load into the main agent’s context at the start of every session, the same wayCLAUDE.mddoes — the directory is just a convenient way to split instructions into separate topic files, not a different mechanism. Several of the rules are facility-specific:facility.mdcarries identity (name, type, mission), and others carry the control-system protocol, the facility timezone, and any safety or operating rules a build profile adds.Fetched on demand — the Open Knowledge Format (OKF) bundle, a directory of Markdown concept documents served by the
osprey_facility_knowledgeMCP server. This holds the facility’s reference knowledge — subsystem descriptions, device specs, procedures, physics notes — and stays out of context until the agent (or you) retrieves it vialist_concepts,read_concept, andsearch.
What You’ll Learn
What the Open Knowledge Format is and where it comes from
The four core ideas: typed documents, progressive disclosure, cross-links, and validation levels
How to structure, configure, and author a facility knowledge bundle
The
osprey knowledgeCLI, thedraft_concepttool, and thefacility-knowledgesubagent
Prerequisites: The concepts need none. To try the mechanics you’ll want
a generated OSPREY project (the control-assistant preset ships a
ready-made bundle).
The two tiers are documented separately:
The always-in-context tier — what the control-assistant preset ships
in .claude/rules/ and how to change it.
The on-demand tier — authoring, configuring, and serving the Open Knowledge Format bundle of concept documents.