# OSAFIS Versioning and Identifiers

OSAFIS citations must identify both the framework version and the referenced element. This document defines the proposed release scheme for 2.0.0-draft.1, the canonical identifiers and the migration from the supplied documents labelled 1.0. That source label records the baseline under revision; it is not evidence of a previous public release. All documents in this corpus share the same framework version.

## Version semantics

The proposed format is MAJOR.MINOR.PATCH with an optional prerelease suffix. A MAJOR revision changes the interpretation or classification obligations of existing cases. Examples include changing a domain boundary, removing a property, or changing the meaning of a mechanism. A MINOR revision adds compatible concepts or explanatory material without changing existing meanings. A PATCH revision corrects spelling, formatting or an error that does not alter those meanings. If an apparent clarification changes which cases qualify, it requires a major change or an explicitly segregated experimental extension.

The source used MAJOR.MINOR. A citation to 1.0 continues to mean the original snapshot and must not be silently rewritten to 1.0.0. The new three-part scheme begins with this proposed revision. The suffix draft.1 indicates a proposal awaiting review. A later draft increments its prerelease number and preserves the earlier snapshot. Removing the draft suffix is a release decision requiring documented review; creating files alone does not authorise that decision.

The release manifest records the version, date, files and cryptographic hashes of the published artifacts, the canonical definitions, source editions for external mappings, known limitations, and migration instructions. Hashes establish that the bytes match a snapshot, not that its scientific claims are correct. The editable sources and human-readable outputs should be generated together to reduce vocabulary drift.

## Canonical layer identifiers

| ID | Display name in 2.0.0-draft.1 |
| --- | --- |
| L1 | Models & Computation |
| L2 | Software & Infrastructure |
| L3 | Data & Knowledge |
| L4 | Perception & World Representation |
| L5 | Interpretation & Objectives |
| L6 | Memory & State Continuity |
| L7 | Planning & Action |
| L8 | Human–System Interaction |
| L9 | Collective & Systemic Interaction |

L means analytical security domain. Numbering is neither a dependency order nor an impact scale. Existing identifiers preserve the lineage of the same domain, but a version-qualified definition is mandatory because this revision changes several boundaries. If later work replaces a domain with a fundamentally different concept, retire its identifier and allocate a new one rather than reusing the old citation.

## Canonical property identifiers

| ID | Display name | ID | Display name |
| --- | --- | --- | --- |
| P01 | Confidentiality | P13 | Action Integrity |
| P02 | Integrity | P14 | Controllability |
| P03 | Availability | P15 | Planning Integrity |
| P04 | Instruction Integrity | P16 | Delegation Integrity |
| P05 | Context Integrity | P17 | Temporal Integrity |
| P06 | Knowledge Integrity | P18 | Decision Integrity |
| P07 | Memory Integrity | P19 | Human Decision Integrity |
| P08 | Identity Integrity | P20 | Attribution Integrity |
| P09 | Objective Integrity | P21 | Trust Integrity |
| P10 | Behavioral Integrity | P22 | Perception Integrity |
| P11 | Semantic Integrity | P23 | World-Model Integrity |
| P12 | Capability Integrity | | |

These are the canonical identifiers from the baseline Versioning and Identifiers document, not the presentation-order numbers used in some other source documents. A migration must inspect the actual property name and meaning when the original record used a bare paragraph number. Do not automatically convert the tenth heading of a source document to P10.

Property overlap is intentional where obligations differ in scope. A single observation can support more than one violated obligation, but a report must explain each assertion. The count of violated properties is not a severity score. Future removal or consolidation must preserve retired definitions and explicit relationships to replacements.

## Canonical mechanism identifiers

| ID | Display name |
| --- | --- |
| M01 | Technical Manipulation |
| M02 | Data Manipulation |
| M03 | Environmental Manipulation |
| M04 | Perception Manipulation |
| M05 | Semantic Manipulation |
| M06 | Contextual Manipulation |
| M07 | Behavioral Manipulation |
| M08 | Memory Manipulation |
| M09 | Identity Manipulation |
| M10 | Objective Manipulation |
| M11 | Capability Manipulation |
| M12 | Human Manipulation |

The mechanism vocabulary contains overlapping descriptors and different levels of abstraction. A mechanism must refer to an evidenced or explicitly hypothesised intervention, rather than merely restating the outcome. Mechanism absence is valid for an accidental failure. Unrepresented mechanisms are recorded in prose with an extension proposal until an identifier is allocated. M00 and other improvised codes must not masquerade as canonical entries.

## Canonical cross cutting dimensions

| ID | Display name |
| --- | --- |
| D1 | Identity, Trust & Authorization |
| D2 | Governance & Accountability |
| D3 | Supply Chain & Provenance |
| D4 | Privacy & Safety |
| D5 | Lifecycle & Change Management |
| D6 | Observability, Logging & Auditability |
| D7 | Resilience & Recovery |

D identifiers are reserved for these dimensions. They must not label an alternative nine-domain diagram. A dimension is a review perspective that can apply across many domains and properties, not a requirement to assign another violation whenever it is relevant.

## Migration from the baseline layer model

| ID | Baseline name | Required reclassification check |
| --- | --- | --- |
| L1 | Model & Computational Foundation | Distinguish model artifacts and computation from hosting software and runtime implementation in L2 |
| L2 | Application & Infrastructure | Include conventional software contracts and verify the location of model execution defects |
| L3 | Data & Knowledge | Separate information resources from retained operational state and from promotion to instructional authority |
| L4 | Environment & Perception | Apply observation and world representation by function, including digital environments; text format alone does not make it inapplicable |
| L5 | Semantic & Behavioral | Reclassify broad behaviour labels by actual interpretation or objective contract, or the responsible neighbouring domain |
| L6 | Memory & Persistent State | Specify retention, ownership, association, update and temporal continuity rather than storage technology |
| L7 | Agent & Action | Include planning and physical actuation regardless of whether the system is called an agent |
| L8 | Human-AI Interaction | Identify an interaction, understanding, authorisation or intervention contract, not merely a human consequence |
| L9 | Systemic & Societal | Require a collective interaction mechanism and contract; move broad impact alone to consequence scope |

The underlying ordering by expanding consequence scope is withdrawn. Existing severity estimates must not be inferred from L numbers. Graph edges now have explicit types, and only actual delegation edges assert delegated authority. A group or cycle can be the locus of a collective failure. Shared components are represented once when that matches the system. A finding can retain several causal domain assignments and need not choose an artificial primary one.

P22 and P23 retain their observation and world-representation lineage, with the revised functional scope documented in Security Properties. Cases originally excluded because they used digital observations require review. Broad P10 Behavioral Integrity labels require a concrete residual behavioral obligation not better captured by a more specific property; a temporal trajectory is required only when it forms part of that obligation. P09 Objective Integrity, P15 Planning Integrity and P18 Decision Integrity must be distinguished by the protected goal, plan and individual decision respectively. M03 and M04 retain the baseline physical emphasis; a digital perception failure does not automatically fit either mechanism. These refinements do not justify changing an old record without reading its evidence.

## Evidence descriptors and record states

E0–E6 are descriptor codes whose labels and definitions are specified in Assessment Methodology. They retain the baseline evidence questions but no longer form a compulsory cumulative ladder. Legacy highest-level values must not be expanded automatically into supported lower facets. Reassess each facet from its underlying artifacts. Descriptor support is distinct from assessment outcome and registry review status.

| Axis | Question | Allowed representation |
| --- | --- | --- |
| Contract result | Was the specified obligation satisfied under this test | A declared oracle with pass fail or inconclusive and observed evidence |
| Assessment outcome | What does the evidence establish about this claim | supported refuted inconclusive quality_issue hazard_only or out_of_scope |
| Evidence facet | What type of support exists and within what scope | supported unsupported not_tested inconclusive or not_applicable for each E code |
| Classification certainty | How securely does the case fit the vocabulary | Reasoned assignment with ambiguous composite or unrepresented cases retained |
| Mapping review | How has the external relationship been reviewed | proposed reviewed disputed or not_assessed |
| Registry review | What administrative decision has been made | submitted under_review accepted rejected withdrawn or superseded |

These axes are not conversions of one another. A syntactically valid record can be scientifically unsupported. Illustrative records have no actual registry decision, and their unexecuted tests cannot be described as observed failures.

## Migration procedure

1. Preserve the original record and the exact framework snapshot it cited. If its version is unknown, record that uncertainty instead of guessing.
2. Identify each referenced element by both identifier and source meaning. Resolve discrepancies between names and section numbers explicitly.
3. Reconstruct entry, failed contract, propagation and consequence from the evidence. Revisit L4, L5, L8 and L9 under the new boundary rules.
4. Record retained assignments, changed assignments, unresolved cases and the reason for each change. A rename can be mechanical; a scope decision requires review.
5. Create a new record revision that links to the prior one. Preserve its observation date, evidence restrictions and original assessment results.
6. Re-evaluate any derived summary, website text, profile applicability or crosswalk affected by the change. A migrated label does not supply new experimental evidence.

## Record identifiers and revisions

The proposed registry prefix is OSAFIS, the project label in the supplied corpus. A registry entry uses OSAFIS-YYYY-NNNN, where the year is submission year and the sequence is allocated within that year. This is a proposed local convention, not a recognised vulnerability authority namespace. Never invent a public assignment or imply equivalence to a CVE identifier. Demonstration cases use EX identifiers such as EX01 and are kept outside the registry namespace.

Entry identifiers persist through review, rejection, correction, withdrawal and supersession. Each substantive change increments entry_revision. A citation includes the entry identifier, entry revision, framework version and retrieval date or immutable snapshot. Duplicate entries link to the retained record without recycling either identifier. Restricted evidence can change accessibility while preserving a public history that avoids exposing sensitive content.

Component, edge, contract, test and artifact identifiers are local to an assessment unless an external namespace is explicitly recorded. For example, a contract identifier C1 within a case does not create a new global OSAFIS property. Schema versions control machine representation separately from the framework meaning. A consumer must reject an unsupported schema version rather than silently interpreting fields under a different release.

## Change control and release decisions

A change proposal states its motivation, affected definitions, boundary cases, compatibility effect and available evidence. The record includes author and reviewer roles, conflicts of interest, dissent and disposition. Proposed process roles must not be presented as appointed independent reviewers. The owner must establish actual governance and a publication licence before claiming an open-governed public release. This document neither selects a legal licence nor grants certification authority.

The next stable release requires consistent artifacts, reviewed migration, explicit scientific limitations and evidence appropriate to its claims. Experiments can remain incomplete if the release makes only a vocabulary proposal, but that status must be visible. If the release claims demonstrated classification reliability or control effectiveness, the supporting study and its limitations must be included. Identifiers make a claim traceable; they do not validate it.