9 September2026. Bounded acquisition closed after one RMC guide and its single named Phoebe implementation. The public record establishes instructional architecture and static mechanisms for drafting rules. It does not establish a named deployment using CCF's policy, a production moderation decision, or a Canadian-funded delivery. No software installation, model inference, endpoint call, harmful-content dataset, account or submission occurred.
The [Using Open Safety Models guide](http[local research file] separates detection, investigation, review and enforcement. It describes models classifying against an existing policy, supporting investigation/review and improving policies. Its suggested two-model arrangement routes uncertain cases to a stronger model that recommends an action for human review; review data should then inform policy revision. This is a recommended design, not a compulsory architecture or measured deployment. Locators: retained implementation-rmc-guide.md lines7–39.
The guide places model, hosting and policy choices with the adopting team. It advises choosing by performance, latency, cost and licence, testing against a suitable dataset, choosing relevant metrics, and distinguishing model errors from inconsistent policy. It allows open/closed hybrids. Its policy section says ROOST does not write policies and points to outside-contributed examples. That institutional description is consistent with hosting a CCF contribution; it does not prove that every ROOST tool uses that contribution. Locators: lines45–95. This source is pinned to Model Community revision 22b3bd48562616f9379eb6fa63abe131346a6de6; the retained earlier README supplies the exact guide link. No exact guide-publication date is inferred from the repository revision.
The guide's investigation example links [Phoebe](http[local research file] describing an agent that analyzes threats and suggests Osprey rules. I followed this one implementation only. Public HEAD returned dfb2bf206fc6cf757b5f10fb4c318ce9a3cce062, committer date7February2026. All findings below concern that pinned source, not every current or privately modified Phoebe deployment.
The [README](http[local research file] lines3–20, describes Osprey rule writing, analytics and Ozone moderation. It claims writing, validation and deployment in its feature summary but expressly marks moderation as unimplemented. Its sample model configuration is Claude Sonnet4.5 via Anthropic, with alternate API backends configurable. It is therefore not evidence of gpt-oss-safeguard, the CCF pack or any particular open model operating on Bluesky. Mentioning the ATProtocol network in the README and prompt is not an adopter account.
The concrete code draws a narrower boundary than the feature summary. [Osprey.save_rule](http[local research file] writes an .sml file under the local ./data/ruleset tree after checking its path/extension. If creating a non-index file and a parent index already exists, it appends a Require entry, optionally conditioned by the supplied require_if. It can overwrite an existing local rule. This creates or changes a candidate rule and its local inclusion, not a recorded remote deployment. Lines165–208.
[validate_rules](http[local research file] runs osprey-cli push-rules ../ruleset --dry-run; the code expressly says the flag validates without pushing. The tool wrapper returns success/error from that validator. Validation thus cannot be represented as production activation or content-policy accuracy testing. No remote push/commit, reviewer approval or active-engine acknowledgement is established by these functions. An external deployment arrangement could supply a later step, but none was inspected. Osprey source lines210–233 and tool definitions lines136–149.
The operator configures the model/API, Osprey endpoint and source/ruleset repositories through settings; the inspected defaults include a particular author's ATProtocol ruleset repository, while README examples use an operator's repository. I did not acquire or inspect that separate ruleset. The Osprey adapter requests labels, features, known actions and UDF documentation from the configured service. These determine the available vocabulary/effects that the agent sees. No universal CCF taxonomy or hardwired CCF pack is established. [Config](http[local research file] lines26–57; Osprey adapter lines59–73; tool definitions lines1–59.
The [source prompt](http[local research file] directs the model to understand target behavior, use available effects, write rules and validate them. It includes examples of account labels and reports for moderation review, and a requirement to validate every new rule. Those are source instructions/examples, not proof an effect ran. The save function itself neither validates nor awaits a human approval; validation is a separate tool plus a prompt instruction. This is a scoped observation about these functions, not an audit of every possible deployment's permission system. Prompt lines31–38,172–209; tool definitions lines103–149.
The MIT licence permits modification and redistribution subject to retaining its notices and disclaimer. It provides software freedom, not access to an Osprey installation, a platform's content or separately licensed models. The source files can consequently be changed by a downstream operator, while the actual chosen version/configuration remains an evidentiary question. Entire21-line LICENSE read. No named actor's production permission or exercise of a right is inferred.
Both direct Ozone methods, [apply_label and remove_label](http[local research file] raise NotImplementedError; the client constructor is also a TODO. The README explicitly marks these as unfinished. Prospective allowed-label/moderator settings and comments in config do not establish enforcement of that permission scheme. The absence of a working direct removal method is not proof that all Osprey deployments lack reversal; they are distinct mechanisms.
The initialization routine clones configured repositories only if their local directories are absent, otherwise logs that they already exist and does not fetch them in that routine. This does not establish any comprehensive update policy. No mandatory corrected-policy notification, recipient synchronization acknowledgement, review reopening or restored-item trace was acquired. Local rule updates and the guide's recommendation to iterate policies are weaker claims than those actual duties/outcomes. Osprey initialization lines32–57 and source-fetch methods75–115.
The relevant chain stops here: operator-selected context and instructions → model-generated candidate rule → local write/inclusion → separate dry-run validation. Activation in the live rules engine, the runtime effect handler, any moderation decision and any later correction require their own records. The generic README term deploy cannot supply the missing steps.
This implementation narrows the adoption claim rather than closing it. ROOST's guide promotes an example that can turn analysis into editable local rules. The selected example's own source exposes unfinished direct moderation and a non-pushing validator. It supports a route for assistance and transferable rules, not a proved uniform restriction system or a government-enforced CCF policy.
The useful next record is a named operator's exact model/prompt/ruleset revision plus the approved activation mechanism and effect-handler configuration, joined to one action and reconsideration outcome. A later Phoebe release or a separate deploying system might resolve the missing step; this pass did not follow either. Root's Pathways and adopter accounts remain independent evidence lanes. No automatic Phoebe/Osprey/Coop→CCF/Elevate/contribution26007 relation is warranted.
implementation-captures.json records10 successful original/API responses plus one reader-failure observation. Original bytes and hashes are retained. Complete reads: guide105lines; Phoebe README133; prompt254; Osprey adapter233; Ozone adapter18; Osprey tool definitions149; config60; MIT licence21. Commit metadata supplies the source pin; repository-tree metadata was used only to choose these files. The remainder of the repository, agent loop, executor/sandbox and external runtime effect handlers were not audited. README claims about sandbox security/performance were not independently tested or adopted as findings.
The pinned guide web reader failed with a cache miss; one ordinary GET succeeded. Subsequent sources used normal public GET. No installation or repository execution was performed, and installation commands in the source remained unevaluated text. No additional implementation link, dataset, model weights or CCF policy test was opened. The prior case, current-work, atlas and ZIP were not changed.