STD-CONTEXT-003 — Bluefly Context Placement Law¶
Standard ID: STD-CONTEXT-003
Applies to: all documentation, execution context, agent definitions, project context, skills, and plugins across the Bluefly estate.
1. The Core Principle: One Fact, One Authority¶
Context does not belong in Scratch, random docs, prompts copied between sessions, or ad hoc repository markdown. Every piece of durable context must have an explicit, singular authority location.
Target architecture:
Forbidden pattern:
2. The Three Governed Context Classes¶
ALL durable context must live in one of the three approved context authorities below.
Class 1: Governed Organizational & Business Knowledge¶
If context represents durable organizational knowledge, product knowledge, customer knowledge, policy context, business context, reusable project knowledge, or governed operational context:
ContextControl is the governed structured context authority.
Examples of Class 1 context: * Products and product capabilities * Organizations and customer accounts * Standards, policies, and architectural decisions * Evidentiary chains and compliance records * Enterprise ontologies and relationships
Law: Do not reduce structured organizational knowledge to loose Markdown files when it belongs as structured, governed ContextControl entities.
Class 2: Project-Specific Execution Context¶
If context belongs specifically to one project/repository and is required by agents working on that project:
Use this exclusively for project-local execution context: * Architecture facts and local conventions * Known technical constraints and integration boundaries * Local environment facts and project-specific runbooks * Verified repository-specific implementation guidance
Law: This context travels with the project. It must not become an estate-wide authority merely because it exists in one repository. It must not duplicate company-wide standards or shared skills.
Class 3: Agent, Skill, and Plugin Context¶
If context describes how an Agent behaves (role doctrine), what a Skill teaches (reusable method), or how a Plugin operates (tool/integration behavior):
Canonical Shared Locations (Relative to Estate Root):¶
BluCity Agent Composition Locations:¶
Rules: * → Agent definition ( or ) * → Skill () * → Plugin ()
3. Classification & Decision Matrix¶
Before creating any durable context file or entity, classify it:
Routing Matrix: | Context Scope / Nature | Canonical Destination | |---|---| | Organizational, product, business, or policy knowledge | ContextControl entity | | Project-specific conventions, architecture, or runbooks | * | | Agent role behavior, doctrine, or persona | ** or ** | | Reusable technical procedure or execution method | | | External system, API, or editor integration logic | *** |
Rule: If none applies, DO NOT CREATE A NEW CONTEXT LOCATION. Determine which existing authority owns it.
4. Prohibited Context Silos¶
The following destinations MUST NOT be used for durable context:
Execution Lifecycle:
5. Context Compilation Model¶
Agents must receive the minimum sufficient context compiled on demand from canonical authorities:
Law: The session context is disposable. The authorities are durable. Never make the session transcript the authority.