version-allowlist

Enforce a version allowlist and identity-record schema for AI model requests.

Updated May 11, 2026
One-click install
npx skills add https://github.com/AesopScott/mojo --skill version-allowlist
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: version-allowlist
Source: https://github.com/AesopScott/mojo/tree/main/harnesses/skills/version-allowlist
Command: npx skills add https://github.com/AesopScott/mojo --skill version-allowlist

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents silent model swaps and unauthorized capability expansion by enforcing a strict version allowlist and identity-record schema for AI model requests.

Core Features & Use Cases

  • Reproducibility Control: Ensures that the exact provider, model, and version are used for every request, preventing unexpected behavior changes.
  • Capability Boundary Management: Provides a structured framework to add new capabilities without accidentally expanding system authority.
  • Use Case: When updating the Identity harness, use this Skill to define a bounded change, verify it with positive and boundary tests, and produce a safe implementation plan.

Quick Start

Use the version-allowlist skill to inspect the current Identity harness boundary and propose a controlled configuration change.

Frequently Asked Questions about version-allowlist

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent silent model swaps and unauthorized capability expansion in AI workflows?

To prevent silent model swaps, enforce a strict version allowlist and identity-record schema for AI model requests. This ensures only approved model versions execute, maintaining strict reproducibility and controlled capability expansion within your harness.

What is the best way to enforce strict reproducibility for AI model requests?

Strict reproducibility is enforced by maintaining a version allowlist that ensures the exact provider, model, and version are used for every request. This prevents unexpected behavior changes during software engineering workflows.

How do I manage capability boundaries when updating an Identity harness?

When updating an Identity harness, use a version allowlist to define a bounded change and verify it with positive and boundary tests. This provides a structured framework to add new capabilities without accidentally expanding system authority.

Does applying a version allowlist require automated testing for safety-gated deployment?

Yes, applying a version allowlist satisfies requirements for bounded change management, automated testing, and safety-gated deployment. It ensures only approved model versions execute within the Identity harness.

Why does uncontrolled model versioning cause unexpected behavior changes?

Uncontrolled model versioning causes unexpected behavior because silent model swaps bypass identity-record schemas. Without a version allowlist, unauthorized capability expansion occurs, breaking reproducibility and safety boundaries.

What are the limitations of relying on a version allowlist for model safety?

The limitation of a version allowlist is that it strictly bounds model execution to approved versions, meaning any unlisted provider or model version is blocked. System authority cannot expand without manually updating the identity-record schema.