Scope and status
This is a design proposal. It does not change the Level 0 contract, introduce a frozen schema or extend the current validator. Runtime permission enforcement, model adaptation and autonomous improvement are not implemented by this profile.
An intertween can seed a skill. The skill is represented as a separate Knowledge Object, preserving links to its origins, evidence and conditions. A description does not demonstrate capability. Evaluation is scoped to a task and context; it does not establish universal reliability.
Objects and relationships
Intention → observation → intertween → candidate skill → evaluation → adoption decision → application → outcome. This is an explanatory path through a branching graph, not a mandatory linear lifecycle.
Several skills can derive from one intertween; one skill can draw on several intertweens. Some questions never become skills. Sources and originating questions retain their independent identities, permissions and histories.
- Skill
- A reusable method for an activity under specified conditions. It may be applied by a human, software, an AI system or a combination.
- Skill Knowledge Object
- A representation of purpose, method, prerequisites, evidence, limitations, governance and history, with references to implementations where relevant.
- Candidate skill
- A proposed method whose evaluation and authorisation must be stated separately.
- Evaluation
- A scoped record of criteria, method and observed results. Evidence, confidence, approval and deployment are separate dimensions.
- Adoption decision
- An attributable decision permitting a defined version and use under a mandate; it is not inferred from a positive evaluation.
- Skill application
- An activity referencing the exact method and relevant execution context, with resulting observations and outcomes.
The translation itself is evidence
“Reduce handling time while preserving explanation quality” must not silently become “minimise response time”. An interpretation record connects the source intention to an operational instruction, its assumptions, author or generating system, uncertainty and review scope.
The reverse direction matters too: a human-readable summary identifies its evidence and material omissions. Generated explanations remain attributable claims; they are not proof of a model’s internal reasoning.
Proposed profile requirements
These requirements are a basis for specification and conformance work. Exact field names, relation terms and interoperability rules remain to be agreed. Reuse existing object, actor, relation and trace structures wherever their semantics fit.
| Area | Requirement to develop |
|---|---|
| Identity and versions | Distinguish a persistent skill identity from the exact version evaluated, authorised or applied. Retain originating intertweens as separate objects. |
| Derivation | Reference source objects, Relation Assertions and contributing methods. Record the author, method and evidence for each asserted dependency. A link alone does not establish causality. |
| Interpretation | Connect the original intention to its operational interpretation, generating actor or system, assumptions, unresolved ambiguity and review. Summaries reference evidence and disclose material omissions. |
| Execution context | Identify relevant model, instructions, tools, inputs and configuration versions. State unavailable records and reproducibility limits. |
| Evaluation | Identify criteria and their version, baseline, evaluator, task and environment, results, failures, counterexamples and limitations. Preserve unsuccessful attempts within the declared recording scope. |
| Authority | Reference the mandate and policy decision for experimentation, adoption and use, including conditions, expiry, withdrawal and escalation. Evaluation is not authorisation. |
| Permissions | Distinguish access, use as context, evaluation, training, execution and onward sharing where relevant. Describe enforcement responsibility separately from policy records. |
| Correction | Append linked challenges, corrections, supersessions and reassessment decisions. Identify affected skills and deployments for review without automatically declaring them invalid. |
| Recursive change | Identify changes to the methods that generate, select or evaluate subsequent skills. Changes to evaluation criteria or authority boundaries require separately governed review. |
| Adaptation lineage | Where available, link authorised training sources, transformations, training configuration, adapters or checkpoints, resulting model version and evaluations. Record missing provenance explicitly. |
| Visibility and control | Declare which components are inspectable, modifiable, externally managed or unavailable. Scope completeness claims to the recording mechanism and evidence available. |
Two use cases across model types
Learning around a model
Instructions, context selection, tools and workflows can change without changing model weights. The skill object connects the procedure to evaluation and use. This can apply to closed-weight and open-weight models.
Learning through model adaptation
Permitted material and evaluated experience may inform training or another adaptation process. Where records are available, the protocol could link authorised sources, transformations and training runs to the resulting model version and evaluation.
| Dimension | Closed weights | Open weights |
|---|---|---|
| Adaptation | Depends on provider-supported facilities and disclosed records. | Potential local fine-tuning or adapters, subject to licence and resources. |
| Evidence | Supplied inputs, available version identifiers, observed outputs, tool actions and evaluations. | The same, plus accessible configurations, adapters and checkpoints. |
| Limits | Weights and provider-side changes may be unavailable. | Accessible weights do not establish complete training provenance or explain behaviour. |
A trained skill is not necessarily a separable component inside model weights. The external Knowledge Object remains a reference for intended capability and evaluation. Training provenance alone does not prove acquisition of the skill.
Skill descriptions and governance records can remain portable when providers change. Equivalent performance is not implied: evaluate the replacement model in its new context. Withdrawing a training source does not automatically remove its influence from existing weights; any retraining, unlearning, retirement or continued-use decision needs its own evidence.
When improvement changes improvement
A task skill improves an activity. An improvement skill changes how further skills are proposed, evaluated or selected. Recursive self-improvement concerns this second loop. Record both the candidate change and changes to the process that generated or evaluated it.
A system must not treat a changed evaluator as evidence of better performance without an explicit comparison and separately governed review. Proposed records do not establish that improvement is real, unlimited or safe.
History and responsibility
Traceability connects records. Transparency makes evidence understandable within a permitted view. Accountability assigns responsibility and makes intervention consequential. Proposer, evaluator, authoriser, operator and responsible responder are operational roles distinct from custody and rights.
Use linked correction and withdrawal events in the proposed Relational Trace. Signatures do not establish truth; checkpoints do not prove all real actions were captured. An execution environment must enforce permissions and stopping conditions. Recording a prohibition or objection does not prove enforcement.
What needs testing
- Can a reviewer follow a skill version to its originating insight, evidence and mandate?
- Are an intention and a materially different interpretation distinguishable?
- Does a failed evaluation remain visible, and is adoption separate from evaluation?
- Can corrected evidence identify dependent skills for reassessment?
- Does a model or evaluator change trigger explicit comparability and review questions?
- Are unavailable execution records and permission-enforcement limits declared?
Structural validity, historical integrity, runtime enforcement and measured effectiveness require separate checks. The fictional example demonstrates navigation of records only.