Support descriptive and executable rules as schema metadata

[mindsocket]

Extend the schema format so that qualitative guidance lives alongside structural validation, rather than only in documentation or agent prompts.

Motivation

JSON Schema validation (via AJV) answers "is this file structurally valid?" but not "is this content good?" There is a class of rules — particularly around planning quality — that are hard or impossible to express in JSON Schema but are important to capture somewhere inspectable.

Examples:

• "Only one opportunity should be active at a time"
• "An opportunity should be framed in the customer's voice, not as a business goal"
• "Test the riskiest assumption across all candidate solutions before committing"

Proposed approach

Add a rules (or similar) key at the entity level in schema files — an array of rule objects.

Two rule modes:

1. Descriptive: human-readable string. Used for documentation, template hints, and as structured input to agent skills (Create an agent skill that knows how to work with OST content #2).
2. Executable: an expression that tooling can evaluate against a set of nodes — for rules that can be mechanically checked (e.g. count(type='opportunity', status='active') <= 1). Format TBD (JSONLogic, a simple custom DSL, or similar).

Start with descriptive rules only. Design the structure to accommodate executable expressions later without breaking changes.

Why this matters

• Agents can query the schema for qualitative guidance on entity types (Create an agent skill that knows how to work with OST content #2) — this is more robust than baking guidance into agent prompts
• Teams using strict schemas get the rules documented alongside the schema itself
• Opens the door to qualitative linting: checking whether content meets the spirit of the model, not just the structure

First use

strict_ost.json (#15) will be the proving ground for the first set of descriptive rules.

Relates to #3 (research findings), #2 (agent skills).