Specifies identity, version, capability, schemas, dependencies, compatibility, resources, license, provenance, evidence, and rollback metadata for a skill package.
Architecture guide: this topic defines a modular tiny-model planning contract. It does not claim that model artifacts exist, are compatible, or execute on this WordPress site.
Manifest identity
Every skill package should carry a stable identifier, semantic version, content hash, source revision, publisher identity, status, and deprecation record.
Compatibility fields
- Standalone model or adapter.
- Exact base model and tokenizer revisions.
- Architecture and layer targets.
- Tensor names, dimensions, dtypes, quantization, and format version.
- Required runtime operators and backend features.
- Input/output schemas and dependency versions.
Governance fields
- License and redistribution conditions.
- Training-data or source disclosures where available.
- Checksums, signatures, SBOM relationships, and review status.
- Benchmark references, known limitations, and last verified UTC.
- Rollback artifact and revocation status.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?