A prompt library is not enough
A prompt library answers a narrow question: what instruction should I use?
A capability registry has to answer a much larger one: what business function is this allowed to perform, under what conditions, using which approved resources, and how do we know it still works?
That is why a CREVOX capability is not stored as a block of text. It is stored as an operating contract:
Purpose + Inputs + Instructions + Context + Tools + Model Requirements + Output Contract + Evaluation + Owner + Risk + Version + Deployment Status
The distinction becomes more important, not less, as AI moves out of individual assistance and into repeatable business processes and agentic execution.
What CREVOX registers
A governed capability record describes the full operating contract around an AI-enabled function.
| Control | What it establishes |
|---|---|
| Capability ID | Stable identity independent of prompt wording |
| Business purpose | Why the capability exists |
| Owner | Who is accountable for the capability |
| Version | Which approved configuration is current |
| Status | Draft, testing, approved, production, superseded, or retired |
| Risk tier | Required level of governance and review |
| Required inputs | Information necessary to run the capability |
| Data permissions | What information may and may not be used |
| Model requirements | Required model characteristics or approved providers |
| Tool permissions | Systems or functions the capability may access |
| Output contract | Required response structure and format |
| Evaluation suite | Tests used to determine acceptable performance |
| Human authority | Decisions that require human approval |
| Dependencies | Other capabilities, tools, data, or systems relied upon |
| Change history | What changed, why, and who approved it |
| Rollback version | Last approved version available for recovery |
The registry therefore describes the business capability, not merely the text used to instruct a model.
Public demonstration
The records below are fictional. They demonstrate how a CREVOX capability registry can be presented without exposing proprietary prompts, client information, internal scoring logic, credentials, or protected system instructions.
Registry explorer
| Capability | Business purpose | Version | Risk | Status |
|---|---|---|---|---|
CVX-DEMO-EXEC-001 | Executive operating brief | 2.3.0 | Medium | Approved |
CVX-DEMO-LEAD-001 | Lead classification and routing | 1.8.0 | Medium | Approved |
CVX-DEMO-CONTENT-001 | Evidence-backed content brief | 3.1.0 | Low | Approved |
CVX-DEMO-RISK-001 | AI-use risk assessment | 1.4.0 | High | Human Review |
CVX-DEMO-WEB-001 | Website page specification | 2.7.0 | Low | Approved |
CVX-DEMO-SOURCE-001 | Source validity assessment | 1.2.0 | Medium | Testing |
A production registry can filter capabilities by business function, status, risk level, approved provider, human-review requirement, owner, data classification, or workflow dependency.
Demo capability: lead classification
The record below shows what a single governed capability looks like in practice.
- Capability ID
CVX-DEMO-LEAD-001- Purpose
- Classify inbound opportunities for routing and human review.
- Current version
- 1.8.0
- Status
- Approved
- Risk tier
- Medium
- Owner
- Revenue Operations
- Human authority
- Required before rejection or material commercial commitment
Permitted data
- Business contact information
- Company information
- Inquiry source
- Approved CRM history
- Submitted project requirements
Prohibited data
- Authentication credentials
- Payment credentials
- Unapproved confidential information
- Sensitive personal data unrelated to qualification
- Data from sources that have not been authorized for this capability
Required output
The capability must produce a structured qualification record containing the opportunity category, qualification confidence, missing information, routing recommendation, supporting evidence, human-review requirement, and any unresolved exceptions.
Evaluation status
42 test scenarios — 41 pass, 1 warning, 0 critical failures.
Production authority
The capability may recommend a routing decision. It may not independently reject a lead, issue a final commercial commitment, alter contractual terms, or send an external response that has not been authorized for automated delivery.
Protected execution layer
Restricted. The public record does not expose system prompts, proprietary instructions, private evaluation cases, internal thresholds, credentials, client data, source locations, security rules, or orchestration logic.
This separation is the point. It allows an organization to make a capability discoverable and auditable without publishing the intellectual property or access controls that make it work.
How capability resolution works
Consider a simple business request:
“Prepare an executive summary of this week’s operating performance using approved CRM and financial information.”
A governed CREVOX execution path resolves that request through the registry rather than through whichever prompt happens to be at hand.
- Request received. The system identifies the requested business outcome.
- Capability resolved. The registry selects the approved capability:
CVX-DEMO-EXEC-001 v2.3.0. - Required sources checked. The capability verifies that required information is available from approved sources.
- Data permissions checked. The execution layer confirms that the data classification is permitted for this capability.
- Model and tool profile selected. The system resolves an approved execution profile rather than assuming that any available model or tool is acceptable.
- Output contract applied. The expected structure, required evidence, limitations, and format are loaded.
- Evaluation checks run. Defined tests assess whether the output meets the capability’s acceptance criteria.
- Human review applied. If the capability requires approval, the system stops at the defined decision boundary.
- Approved output released. Only the authorized result proceeds to its intended business destination.
The important change is what the organization is now able to ask. Not which prompt did we use? but which approved capability produced this result, using which version, sources, tools, controls, and evaluation standard?
Version control matters
AI instructions should not silently change in production. A registry treats each meaningful change as a controlled version.
Example: CVX-DEMO-EXEC-001
Version 2.2 — Executive summaries may not exceed 750 words.
Version 2.3 — Executive summaries default to 300–500 words and may exceed that range only when necessary to preserve a material risk, exception, dependency, or decision.
Change record
- Reason
- Improve executive usability without suppressing material information.
- Changed by
- Capability Owner
- Evaluation
- 38 of 38 required tests passed
- Approval
- Human reviewer
- Previous production version
- 2.2
- Rollback available
- Yes
Versioning creates a traceable relationship between the instructions, the operating assumptions, the evaluations, and the business process affected by the change.
Capability lifecycle
A governed AI capability moves through an explicit lifecycle:
Draft → Testing → Review → Approved → Production → Superseded → Retired
Promotion depends on more than whether the prompt appears to work. A production decision can consider version identity, accountable owner, evaluation results, required source availability, data permissions, model compatibility, tool permissions, risk classification, human-review requirements, effective date, dependencies, and rollback readiness.
The same controls make retirement possible. If a capability is no longer valid, the organization should know where it is used before removing it.
Why this matters for agentic AI
An AI agent is rarely just a prompt. It may combine system instructions, business rules, tools, APIs, source documents, memory, credentials, model configurations, output schemas, automated actions, and human approval gates.
Without a registry, those elements become tightly coupled inside individual applications or vendor platforms. CREVOX treats them as governed components of a business capability, which creates a clear boundary between what the business intends and how a particular model, provider, tool, or application currently executes it.
That boundary reduces avoidable dependency on any one AI provider and makes future migration more manageable.
Multi-provider and model portability
A capability should not have to be reinvented every time an organization changes models. The registry separates the business contract from the execution adapter.
CAPABILITY
CVX-DEMO-SOURCE-001
|
+-- OpenAI execution profile
|
+-- Anthropic execution profile
|
+-- Approved local-model profile
|
+-- Future provider profile
The capability retains its purpose, inputs, output contract, evaluation requirements, risk classification, ownership, lifecycle, and decision authority. Provider-specific execution details can change independently.
This does not mean that all models are interchangeable. A provider or model change still requires evaluation. It means the organization has a controlled system for determining whether the replacement is acceptable.
Where businesses can use a capability registry
The concept applies anywhere AI has moved beyond occasional individual use.
Executive management
Operating briefs, decision summaries, scenario analysis, exception identification, and meeting preparation.
Sales and revenue operations
Lead classification, opportunity research, account briefs, proposal preparation, pipeline analysis, and next-action recommendations.
Marketing
Research synthesis, campaign analysis, content planning, evidence-backed article development, and customer and market intelligence.
Finance and operations
Reconciliation, exception classification, report generation, document review, and structured variance analysis.
Digital experience
Page specifications, content governance, SEO and AI-discovery analysis, structured-data recommendations, and quality review.
Governance and security
AI-use assessments, risk classification, data-permission checks, approval workflows, evaluation management, and controlled release.
How the registry fits within CREVOX
The Prompt + Capability Registry is not intended to operate as an isolated prompt-management tool. It is one layer of a broader CREVOX governance architecture.
BUSINESS NEED
↓
STRUCTURED INTAKE
↓
CAPABILITY REGISTRY
↓
GOVERNED WORKFLOW / AGENT
↓
MODEL + TOOL + DATA ROUTING
↓
EXECUTION
↓
EVALUATION + HUMAN REVIEW
↓
BUSINESS OUTCOME
↓
EVIDENCE + IMPROVEMENT
The registry provides the controlled identity of the reusable capability. Other CREVOX systems determine when it should be used, what context it receives, how it executes, what evidence must be retained, and whether a result is authorized to proceed.
What has already been built and verified
The Prompt + Capability Registry builds on operational CREVOX architecture rather than beginning as an isolated concept. CREVOX v1.0 includes:
- a production master orchestration prompt;
- phase-specific workflow prompts;
- JSON Schema contracts;
- reusable templates and populated examples;
- quality, security, content, accessibility, performance, SEO/GEO, analytics, design, and future-proofing standards;
- Claude Code and Codex repository adapters;
- a vendor-neutral core adapter;
- provider registry architecture;
- migration and change-impact controls;
- versioned contracts;
- lifecycle and deprecation rules;
- CLI-based validation;
- structured source, decision, assumption, risk, evidence, and traceability workflows.
The July 21, 2026 CREVOX v1.0 verification recorded successful checks for JSON parsing, Python compilation, JSON Schema validation, package integrity, clean initialization, active-workspace validation, provider-registry controls, migration and lifecycle contracts, and documented expansion scenarios.
These controls establish the architectural foundation required for a governed capability registry. They do not mean that every possible capability, provider, workflow, or production environment has already been implemented or certified. Each production deployment still requires project-specific security, privacy, legal, performance, accessibility, usability, operational, and business validation.
What a production CREVOX registry can provide
- Registry discovery. Search, filter, compare, and identify approved capabilities across the organization.
- Controlled versioning. Maintain immutable historical versions and explicit production aliases.
- Evaluation management. Associate required test suites and results with each capability version.
- Dependency tracking. Identify the workflows, tools, models, data sources, and downstream systems affected by a change.
- Provider profiles. Document which AI providers or local models have been validated for a capability.
- Human-authority boundaries. Define where AI may recommend, draft, classify, execute, or stop for approval.
- Data governance. Restrict which information classifications may be used.
- Change impact. Determine what must be re-tested when instructions, models, tools, data sources, schemas, or policies change.
- Rollback. Return to a previously approved version when a release fails or produces unacceptable behavior.
- Retirement. Remove obsolete capabilities without losing history, ownership, or dependency information.
When does a business need this?
Not every organization needs a formal AI capability registry on day one. The need becomes stronger when any of the following is true:
- AI is used in repeatable business processes.
- Multiple employees use shared prompts or instructions.
- Custom GPTs, Claude projects, agents, or internal AI applications are proliferating.
- AI accesses business systems or proprietary information.
- Different models or providers are used for the same business function.
- Outputs influence customers, pricing, commitments, approvals, or operating decisions.
- Important AI knowledge is difficult to locate or owned by individuals.
- Prompt changes are being made without testing.
- Leadership cannot answer which AI capabilities are currently operating across the company.
- The organization expects AI use to expand.
At that point, the cost of uncontrolled AI assets can begin to exceed the cost of governing them.
The larger business question
Most companies are still asking which AI tool should we buy?
The more durable question is which AI-enabled capabilities should this business own, how should they be governed, and how should they survive changes in employees, models, vendors, applications, and technology?
That is the problem the CREVOX Prompt + Capability Registry is designed to address.