1.Abstract
This specification defines a lifecycle model for AI skills. It names four stages — Incubating, Validated, Certified, Deprecated — and the explicit, evidence-bearing gate criteria a skill must satisfy to transition between them. It defines the format of the durable report that records each transition, a JSON Schema for that report, and the conformance rules that distinguish a valid maturity gate review from an invalid one. The model operationalizes the Innorve Native Mode tenets of evaluating before trusting and governing before scaling.
2.Problem statement
2.1The problem
AI skills accumulate as undocumented, unowned, undeprecated technical debt because there is no shared lifecycle model. A skill is built, demonstrated, and exposed to production traffic without a recorded verdict on whether it is fit for that traffic. Owners rotate. Eval suites drift. Skills that should have been retired remain reachable. Skills that should have been promoted carry production load on hope. Production-ready becomes a feeling instead of a checklist, and the auditor cannot tell which is which.
2.2What this spec solves
This specification defines four lifecycle stages and the gate criteria for transitions between them. Each gate enumerates the criteria a skill must satisfy, the evidence that supports each criterion, and the format of the report that records the verdict. The result is that the question "is this skill ready to carry this traffic?" has a written, citable answer.
2.3What this spec does not solve
This specification does not define:
- Specific test methodologies. What an eval suite contains, how it is scored, and how regression cases are constructed are addressed separately. This spec only requires that an eval suite exists and that its pass rate meets a threshold.
- Governance binder content. The artifacts that compose a governance binder — model card, risk register, audit trail config — are defined in
IM-03(Evidence-by-Design Framework). This spec only requires that a conforming binder exists. - Enforcement runtime. How a runtime, registry, or CI pipeline detects an unconforming skill and blocks its invocation is an implementation concern outside this specification.
3.Conformance language
The capitalized keywords below carry the meanings defined in the following table wherever they appear in this specification. Their use is normative.
| Keyword | Meaning |
|---|---|
| MUST | An absolute requirement. A document, review, or implementation that fails a MUST clause is not conforming. |
| MUST NOT | An absolute prohibition. The same conformance consequence applies. |
| REQUIRED | Synonymous with MUST when applied to a field, criterion, or artifact. |
| SHOULD | A strong recommendation. An implementation that omits a SHOULD behavior remains conforming but accepts the consequences and documents the rationale. |
| SHOULD NOT | A strong recommendation against. The same documentation expectation applies. |
| MAY | An option. An implementation that exercises or omits a MAY behavior is equally conforming. |
| OPTIONAL | Synonymous with MAY when applied to a field. |
| CONDITIONAL | REQUIRED only when a stated precondition holds. A conditional clause that does not apply is satisfied vacuously. |
4.Definitions
The terms below carry the meanings given here for the duration of this specification.
4.1Skill
A discrete, named unit of AI behavior governed by a Skill Contract conforming to IM-04. A skill is the atomic unit to which a lifecycle stage applies.
4.2Lifecycle stage
A named state in the lifecycle of a skill. A skill MUST be in exactly one of the four stages defined in Section 5 at any point in time.
4.3Gate
A defined transition between two lifecycle stages, expressed as an enumerated set of criteria. A gate is not crossed by intent; it is crossed by satisfying its criteria with evidence.
4.4Gate review
The act of evaluating a skill against the criteria of a gate at a specific point in time. A gate review yields a verdict of passed, failed, or partial.
4.5Gate report
The durable artifact produced by a gate review. Its required shape is defined by Sections 10 and 11.
4.6Criterion
A single, evaluable requirement within a gate. Each criterion is either satisfied or not satisfied for a given gate review; partial satisfaction is not defined at the criterion level.
4.7Evidence
A reference to an artifact — a file, a CI run, an attestation, a deployment record — that demonstrates a criterion is satisfied. Evidence MUST be durably addressable for the lifetime of the report; an evidence reference that resolves only to a transient location is not conforming.
4.8Accountable owner
The named human or team mailbox declared in the Skill Contract’s skill.owner field. Authority over the skill, and accountability for its behavior in production, rest with the accountable owner.
4.9Conforming gate review
A gate review that records a status of passed or failed against every REQUIRED criterion of the relevant gate, applies the CONDITIONAL criteria whose preconditions hold, and is conducted by a reviewer independent of the accountable owner per Section 15.1. A review that omits a REQUIRED criterion is not conforming, regardless of its verdict.
4.10Conforming Maturity Gate Report
A document that (a) validates against the JSON Schema in Section 11, (b) faithfully records the results of a conforming gate review per Section 4.9, and (c) is preserved in append-only history per Section 15.2.
5.Lifecycle stages
The Maturity Gate Model defines four stages. A skill MUST be in exactly one stage at any point in time. Transitions occur only via the gates in Sections 6 through 8.
5.1Incubating
- Invocation rules: the skill MAY be invoked in development and test environments only.
- Traffic permissions: the skill MUST NOT carry production traffic.
- Owner requirements: an accountable owner MUST be identified in the Skill Contract; a backup owner is RECOMMENDED.
- Review frequency: none required. A skill that remains Incubating for more than 90 days SHOULD be either advanced or formally abandoned.
5.2Validated
- Invocation rules: the skill MAY be invoked in production under strict guards: feature flag, low-traffic shadow mode, or restricted to internal users.
- Traffic permissions: bounded production traffic is permitted; full production traffic is not.
- Owner requirements: an accountable owner and a backup owner MUST be named. The owner is accountable for the eval suite.
- Review frequency: SHOULD be re-reviewed at least every 90 days while the skill remains in Validated. A skill that is Validated for more than 180 days without an attempt at the Certification Gate SHOULD be re-justified or retired.
5.3Certified
- Invocation rules: the skill MAY be invoked in production with the decision authority declared in its Skill Contract.
- Traffic permissions: normal production traffic is permitted, subject to the rate, role, and approval constraints declared in the contract.
- Owner requirements: accountable owner, backup owner, and an escalation path MUST be documented. A published Governance Binder conforming to
IM-03MUST exist. - Review frequency: periodic re-certification per Section 9 is REQUIRED. A skill whose re-certification is overdue MUST revert to Validated automatically per Section 15.3.
5.4Deprecated
- Invocation rules: no new invocations are permitted after the deprecation effective date. Read-only access for audit purposes is preserved.
- Traffic permissions: none. Callers that attempt invocation MUST receive a structured error indicating deprecation and the successor skill, if any.
- Owner requirements: the accountable owner MUST remain named for the duration of the regulatory retention window even after the skill is no longer reachable.
- Review frequency: none. The deprecation record itself is the durable artifact.
6.Validation Gate (Incubating → Validated)
The Validation Gate is the first formal review. A skill that passes the Validation Gate MAY carry production traffic under the strict guards described in Section 5.2.
| Criterion | Required | Evidence required |
|---|---|---|
| A Skill Contract conforming to IM-04 v0.1 MUST exist | Required | Path to contract YAML in repo |
| The contract MUST declare at least 5 evals | Required | Path to eval file |
| The eval suite MUST pass at >= 80% | Required | Eval run report from CI |
| An accountable owner MUST be documented | Required | Email address in skill.owner |
| A backup owner MUST be documented | Required | Secondary contact in repo metadata |
| The skill MUST have been reviewed by at least one engineer who is not the author | Required | Code review approval |
| A deployment runbook MUST exist | Required | Path to runbook |
| The skill MUST have been deployed to staging successfully at least once | Required | Deployment record |
7.Certification Gate (Validated → Certified)
The Certification Gate grants a skill normal production traffic and the decision authority declared in its contract. It is the most rigorous of the three transition gates and typically requires evidence accumulated over a 30-day Validated period.
| Criterion | Required | Evidence required |
|---|---|---|
| All Validation Gate criteria MUST continue to be met | Required | Re-verification of Section 6 |
| The eval suite MUST pass at >= 95% | Required | 30-day eval run history |
| At least one regression test MUST exist, drawn from a real production observation | Required | Regression case file |
| A Governance Binder conforming to IM-03 MUST exist | Required | Path to binder |
| The Governance Binder MUST include: model card, risk register, eval report, prompt register, audit trail config | Required | Each artifact present |
Where risk_class >= medium: required approvals per the Skill Contract MUST have been collected | Conditional | Approval records in audit trail |
| An incident response runbook MUST exist | Required | Path to runbook |
| A rollback runbook MUST have been tested at least once in staging | Required | Rollback test record |
Where risk_class = high or critical: an external review (security, compliance, or legal) MUST have signed off, attested in writing, dated, and named | Conditional | Review attestation |
8.Deprecation Gate (Certified → Deprecated)
Deprecation is a gate, not a deletion. A skill that is silently turned off without passing the Deprecation Gate leaves callers stranded and audit trails ambiguous. Retirement is an event with criteria.
| Criterion | Required | Evidence required |
|---|---|---|
| A reason for deprecation MUST be documented | Required | Deprecation notice file |
| A successor skill (or an explicit, accepted gap) MUST be identified | Required | Successor skill ID or gap statement |
| A migration plan for callers MUST be published | Required | Migration doc |
A sunset date MUST be set, with at least 90 days notice where risk_class >= medium | Required | Date in deprecation field |
| All callers MUST have been notified | Required | Notification log |
| The audit trail MUST be preserved per the regulatory retention rules in Section 15.5 | Required | Retention plan documented in evidence config |
9.Periodic re-certification
Certified skills MUST be re-certified periodically. The recommended cadence is keyed to the risk class declared in the Skill Contract:
risk_class = low— annualrisk_class = medium— every 6 monthsrisk_class = high— quarterlyrisk_class = critical— monthly
A re-certification re-runs the Certification Gate criteria against current state. A skill that fails re-certification MUST revert to Validated until the gaps are closed. It MUST NOT silently continue at Certified.
10.The Maturity Gate Report
Every gate review MUST produce a Maturity Gate Report. The report is the durable, citable artifact that records the verdict and the evidence behind it.
# innorve-maturity-gate-report v0.1
schema: innorve.maturity-gate.v0.1
skill_id: bank.lending.heloc-eligibility-check
skill_version: 1.2.0
report_date: 2026-04-25
reviewer: meera.iyer@example-bank.com
gate_attempted: certification # validation | certification | deprecation
result: passed # passed | failed | partial
criteria_results:
- criterion: skill_contract_exists
status: passed
evidence: contracts/heloc-eligibility-check.yaml
- criterion: eval_pass_rate_95
status: passed
evidence: ci/eval-runs/2026-04-24.json
note: "30-day average 0.967, no regressions in last 30 days"
- criterion: governance_binder
status: failed
evidence: missing
action_required: "Author governance binder per IM-03 by 2026-05-15"
next_review: 2026-10-25The report is append-only. Failed reviews are part of the historical record per Section 15.2 and MUST NOT be deleted. A skill that fails the Certification Gate, then passes it three weeks later, has two reports — both retained, both citable.
11.JSON Schema (normative)
The following JSON Schema is the normative reference for v0.1 validation of a Maturity Gate Report. A document that fails JSON Schema validation against this schema MUST NOT be considered a conforming Maturity Gate Report. Implementations MAY extend the schema with additional properties provided the required properties below are preserved and unknown properties do not change the meaning of any defined property.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://innorve.academy/spec/maturity-gate/v0.1.json",
"title": "Innorve Maturity Gate Report",
"type": "object",
"required": [
"schema",
"skill_id",
"skill_version",
"report_date",
"reviewer",
"gate_attempted",
"result",
"criteria_results"
],
"properties": {
"schema": {
"type": "string",
"const": "innorve.maturity-gate.v0.1"
},
"skill_id": { "type": "string", "pattern": "^[a-z0-9.-]+$" },
"skill_version": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$" },
"report_date": { "type": "string", "format": "date" },
"reviewer": { "type": "string", "format": "email" },
"gate_attempted": {
"type": "string",
"enum": ["validation", "certification", "deprecation"]
},
"result": {
"type": "string",
"enum": ["passed", "failed", "partial"]
},
"criteria_results": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"required": ["criterion", "status"],
"properties": {
"criterion": { "type": "string" },
"status": { "type": "string", "enum": ["passed", "failed"] },
"evidence": { "type": "string" },
"note": { "type": "string" },
"action_required": { "type": "string" }
}
}
},
"next_review": { "type": "string", "format": "date" }
}
}12.Valid example
The following is a complete, conforming Maturity Gate Report for a passing Certification Gate review of a healthcare prior-authorization triage skill. Every REQUIRED criterion of Section 7 carries a passed status and a durable evidence reference. The CONDITIONAL clauses for risk_class >= medium apply and are satisfied.
# innorve-maturity-gate-report v0.1
schema: innorve.maturity-gate.v0.1
skill_id: health.prior-auth.triage-router
skill_version: 2.0.0
report_date: 2026-04-12
reviewer: r.santos@example-health.org
gate_attempted: certification
result: passed
criteria_results:
- criterion: validation_gate_criteria_continue_to_be_met
status: passed
evidence: gates/validation/2026-04-10.report.yaml
- criterion: eval_pass_rate_95
status: passed
evidence: ci/eval-runs/triage-router/30d-2026-04-12.json
note: "30-day average 0.972, 0 regressions"
- criterion: regression_test_from_production_observation
status: passed
evidence: evals/regression/PA-INC-2026-0317.yaml
note: "Drawn from incident PA-INC-2026-0317 (false-route to denial path)"
- criterion: governance_binder_exists
status: passed
evidence: governance/triage-router/binder-v2.0.0.md
- criterion: governance_binder_includes_required_artifacts
status: passed
evidence: governance/triage-router/manifest.yaml
note: "model_card, risk_register, eval_report, prompt_register, audit_trail_config all present"
- criterion: required_approvals_collected
status: passed
evidence: approvals/2026-04/triage-router-v2.0.0.json
note: "risk_class=high; clinical-safety and privacy-officer signoffs attached"
- criterion: incident_response_runbook_exists
status: passed
evidence: runbooks/triage-router/incident-response.md
- criterion: rollback_runbook_tested_in_staging
status: passed
evidence: ci/rollback-tests/triage-router/2026-04-08.log
- criterion: external_review_signoff
status: passed
evidence: attestations/security-review-2026-04-09.pdf
note: "Signed by S. Park, Security Architecture, 2026-04-09"
next_review: 2026-07-1213.Invalid examples
The following three examples are not conforming Maturity Gate Reports. Each illustrates a distinct class of conformance violation, the reasoning, and the minimal fix.
13.1Missing REQUIRED criterion result
# INVALID — missing REQUIRED criterion
schema: innorve.maturity-gate.v0.1
skill_id: saas.support.refund-classifier
skill_version: 0.4.0
report_date: 2026-03-30
reviewer: t.nguyen@example-saas.com
gate_attempted: validation
result: passed
criteria_results:
- criterion: skill_contract_exists
status: passed
evidence: contracts/refund-classifier.yaml
- criterion: eval_pass_rate_80
status: passed
evidence: ci/eval-runs/2026-03-29.json
- criterion: accountable_owner_documented
status: passed
evidence: contracts/refund-classifier.yaml#owner
# NOTE: backup_owner_documented, second_engineer_review,
# deployment_runbook_exists, staged_deployment_record are absent
Violation. Section 6 enumerates eight REQUIRED criteria for the Validation Gate. The report records only three. Per Section 4.9, a review that omits a REQUIRED criterion is not a conforming gate review, regardless of its verdict. The result: passed verdict cannot stand because the gate has not been fully evaluated.
Fix. Add a passed or failed entry for each of the missing criteria with its supporting evidence. Where evidence cannot be produced, record the criterion as failed with an action_required note and change the report result to failed or partial as appropriate.
13.2Result inconsistent with criteria_results
# INVALID — verdict inconsistent with criteria
schema: innorve.maturity-gate.v0.1
skill_id: bank.deposits.kyc-screening
skill_version: 3.1.0
report_date: 2026-04-05
reviewer: a.okafor@example-bank.com
gate_attempted: certification
result: passed # <-- inconsistent
criteria_results:
- criterion: validation_gate_criteria_continue_to_be_met
status: passed
evidence: gates/validation/2026-03-30.report.yaml
- criterion: eval_pass_rate_95
status: passed
evidence: ci/eval-runs/30d-2026-04-04.json
- criterion: regression_test_from_production_observation
status: passed
evidence: evals/regression/KYC-INC-2026-0211.yaml
- criterion: governance_binder_exists
status: failed # <-- a REQUIRED criterion failed
evidence: missing
action_required: "Author governance binder per IM-03 by 2026-04-30"
- criterion: incident_response_runbook_exists
status: passed
evidence: runbooks/kyc-screening/ir.md
- criterion: rollback_runbook_tested_in_staging
status: passed
evidence: ci/rollback-tests/kyc/2026-04-02.log
Violation. A Certification Gate review in which any REQUIRED criterion is recorded as failed MUST NOT carry a top-level result of passed. The verdict contradicts the contents of criteria_results and is therefore not a faithful record of the review per Section 4.10.
Fix. Change the top-level result to failed. The skill remains in its current stage (Validated) until the missing governance binder is produced and a fresh Certification Gate review is recorded. The failed report MUST be retained as part of the append-only history per Section 15.2.
13.3Reviewer is the skill owner (independence violation)
# INVALID — independence violation
schema: innorve.maturity-gate.v0.1
skill_id: saas.billing.dunning-composer
skill_version: 1.0.0
report_date: 2026-04-15
reviewer: l.alvarez@example-saas.com # <-- same as skill.owner
gate_attempted: certification
result: passed
# Skill Contract excerpt for context:
# skill:
# id: saas.billing.dunning-composer
# owner: l.alvarez@example-saas.com # <-- identical
Violation. Section 15.1 requires that the gate reviewer MUST NOT be the skill owner. The reviewer email and the skill.owner email are identical, so the review is not independent. Per Section 4.9, an independence violation disqualifies the review from being conforming, regardless of its substantive findings.
Fix. Re-conduct the review with a reviewer who is not the accountable owner. For Certification Gates of skills with risk_class >= high, two independent reviewers are RECOMMENDED. Record the prior, non-conforming attempt as part of the append-only history; do not delete it.
14.Versioning
14.1Spec versioning
This specification uses semantic versioning. Versions in the v0.x.y series are pre-stable. Version v1.0.0 will be the first stable release. Pre-stable versions MAY introduce breaking changes between minor revisions; stable versions MUST NOT.
14.2What each version component means
- MAJOR — a breaking change to the schema, the gate criteria, or the conformance rules. A document conforming to
vN.x.yis not guaranteed to conform tov(N+1).0.0. - MINOR — a backward-compatible addition: a new optional field, a new enum value that tools can ignore, a new sub-object, or a new CONDITIONAL criterion whose precondition is opt-in.
- PATCH — an editorial change that does not affect validation: clarification, typo fix, or example rewrite.
14.3Schema declaration
Reports MUST declare the spec version they conform to via the schema field. The value MUST be innorve.maturity-gate.v0.1 for documents conforming to this version. Tooling that consumes a report with a missing or unrecognized schema field MUST NOT treat it as conforming.
14.4Deprecation notice for MAJOR changes
A MAJOR version of this specification MUST be announced at least 12 months before the prior MAJOR is withdrawn. During the overlap period, both versions are conforming, and tooling SHOULD accept reports declaring either schema string.
15.Security and governance considerations
15.1Independence
The gate reviewer MUST NOT be the skill owner. For Certification Gates of skills with risk_class >= high, two independent reviewers are RECOMMENDED. Independence is the property that makes the gate report credible to a third party; without it the report is self-attestation and cannot be relied upon by an auditor.
15.2Append-only history
Maturity Gate Reports are append-only. Failed reviews MUST remain part of the historical record. Erasing or overwriting a failed review is a conformance violation and removes the evidence that demonstrates how the skill earned the verdict it currently holds.
15.3Re-certification cadence
For risk_class = critical skills, re-certification at the cadence specified in Section 9 (or more frequent) is REQUIRED. Skipping re-certification on a Certified skill MUST cause an automatic revert to Validated status. Continuing to invoke a skill at Certified privileges after the re-certification deadline has passed is a conformance violation attributable to the runtime, not to the report.
15.4Approval validity
A criterion that requires external review (security, compliance, or legal) sign-off MUST be supported by a dated, named attestation. Verbal approvals are not conforming. The attestation MUST identify the reviewer, the reviewed artifact, the date, and a reference that can be re-fetched at audit time.
15.5Evidence preservation
Evidence linked from a Maturity Gate Report MUST be preserved for the longest applicable regulatory retention period for the domain in which the skill operates. Common minima include 7 years for financial systems, 6 years for systems handling protected health information, and 10 or more years for some regulated systems in other jurisdictions. Where multiple regimes apply, the longest applicable retention period governs.
15.6Innorve Native Mode alignment
This specification operationalizes two tenets of Innorve Native Mode:
- Tenet 2 — Evaluate before trusting. The Validation and Certification Gates make the eval suite a precondition for production traffic, not an afterthought. Trust is recorded as a verdict against criteria, not asserted as a feeling.
- Tenet 3 — Govern before scaling. The Certification Gate requires a published Governance Binder, named approvals, and an independent reviewer before a skill carries normal traffic. Governance precedes scale by construction.
The gate criteria are the mechanism that makes both tenets enforceable rather than aspirational.
16.Reference implementation
The /innorve-maturity-gate skill in the public Innorve Method repository (Innorve-Inc/innorve-method) implements this specification interactively. It walks an engineer through the applicable gate, collects evidence references, validates the result against the schema in Section 11, and emits a conforming Maturity Gate Report.
17.Implementations
This space is intentionally empty. If you implement this specification in a tool, runtime, registry, editor, or CI integration, open a Spec Implementation issue at github.com/Innorve-Inc/innorve-method/issues/new and you will be listed here.
Listings are unranked, unfiltered, and not endorsements. The list exists so that downstream users can find each other.
18.Citation
To cite this specification:
Innorve Maturity Gate Model, v0.1 (2026). Innorve Method, IM-05. Innorve Academy. https://innorve.academy/spec/maturity-gate