# OSAFIS Research Vision

OSAFIS proposes a common representation for analysing security failures in intelligent systems. Its purpose is to connect the security contract that failed to the component or relationship involved, the mechanism of influence, the evidence supporting the finding, and the consequences within a declared system boundary. Researchers can use this representation to compare findings. Engineers can use it to identify controls and assessment obligations. Neither use establishes that the representation is complete or that a system is secure.

The current specification is 2.0.0-draft.1. It defines a research method and a candidate vocabulary. Independent evaluation of classification reliability, assessment usefulness and coverage remains necessary. OSAFIS does not claim recognition as a standard, authority to certify systems, an operational public registry, or established industry adoption.

## The problem being addressed

An intelligent system includes more than its learned model. A deployment may combine application code, training and retrieval data, observations, retained state, tool access, human approval and dependencies shared with other systems. Its security depends on the contracts between these functions as well as the integrity of each component. A valid credential can permit an operation that a user never requested. A retrieved document can provide useful evidence while having no authority to change the task. An accurate observation can contain text that the system must not treat as an instruction.

These distinctions require an account of authority and intended use. Conventional access control, software security and operational risk management remain part of that account. Existing AI security work already provides terminology, threat knowledge and mitigation guidance. The research opportunity for OSAFIS is to test whether a consistent contract-centred representation makes the relationship between these resources and a particular system easier to analyse.

The proposal focuses on identifiable failures and defensible evidence. A plausible attack description does not establish that a system permits it. A surprising output does not, by itself, establish a security vulnerability. A demonstrated failure in one configuration does not establish its prevalence across products. Each statement should retain the assumptions and observations that make it meaningful.

## Scope and intended users

The intended scope includes learned and symbolic models, language and multimodal applications, retrieval systems, adaptive services, tool-using agents, embodied systems and interacting deployments. Applicability follows the functions present in the assessed system. A digital agent may observe and estimate an environment without a physical sensor. A predictive service may have no persistent task memory. A system marketed as autonomous may still contain human approval boundaries that determine its effective authority.

Security researchers need stable concepts, examples and refutable classification rules. System builders need security contracts with observable acceptance criteria and accountable control owners. Assessors need an evidence package that distinguishes what they observed from what they inferred. Domain specialists need a way to adapt tests to actual hazards, users and operating constraints. Affected people need their interests and avenues for challenge to be represented when an assessment makes claims about them.

The framework can describe safety-relevant failures, including accidental ones, where they concern a declared security contract or a material coupling with an intelligent system. It does not replace a domain safety assessment, clinical study, legal analysis or general account of social harms. Purely human organisational problems with no material connection to the intelligent system fall outside this scope. Unclear cases remain explicitly unresolved until the assessment boundary is justified.

## The proposed representation

Nine provisional analytical domains describe security responsibilities. They are 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 and L9 Collective & Systemic Interaction. Their numbers identify them. They do not specify execution order, increasing intelligence, severity or expanding consequence.

Twenty-three property identifiers describe obligations that may apply in more than one domain. Twelve mechanism identifiers provide overlapping descriptors for adversarial influence. Seven cross-cutting dimensions prompt examination of identity and authority, governance, provenance, privacy and safety, change management, observability, and recovery. These counts describe the present vocabulary. Their optimality has not been demonstrated.

A separate graph records actual components, humans and shared resources, with typed relationships. A component can implement several domains. A common model should appear as a shared component when several agents actually depend on the same artifact, rather than as fictitious independent copies. Observations, information exchange and state synchronisation do not automatically transfer authority. Collective contracts can concern a group or feedback cycle without reducing to one defective pairwise connection.

Findings distinguish entry points, failed contracts, participating domains, propagation and impact. A downstream domain is not automatically vulnerable because an attack reaches it. Wide impact alone is not an L9 finding. Assessors may identify multiple causal failures or leave a classification ambiguous, without forcing an artificial primary layer.

## Research principles

Definitions should support decisions. Each domain must identify a protected function or relationship and explain how it differs from its neighbours. Each property must specify an obligation that can be instantiated as a testable contract. A property name such as integrity or trust is insufficient without a subject, authorised change rule, relevant assumptions and observable violation.

Evidence should remain traceable. Reports should preserve configuration, versions, input provenance, test boundaries, outcomes, contrary evidence and restrictions on reproduction. Openness does not require publishing private data or a hazardous payload. Restricted evidence should have a declared access process and clearly stated consequences for independent verification.

Claims should remain proportionate. Classification coverage, attack detection, mitigation effectiveness and residual risk are separate questions. A framework can describe a failure it cannot automatically detect. A control can block a tested scenario without eliminating the broader class. An empirical study can support a bounded conclusion without proving absence of future failures.

Revisions should be reviewable. Disagreement is evidence about unclear boundaries, competing causal explanations or differing threat assumptions. The process should preserve this information. Changes to domain scope require a migration record, not silent reinterpretation of old findings. External mappings should preserve their source edition and distinguish a conceptual relationship from an equivalence claim.

## Deliverables and their responsibilities

Foundational Concepts defines the unit of analysis and the terminology shared by the corpus. Security Layers defines the nine domains and their boundary rules. Security Properties defines the obligations used to construct security contracts. Threat Model records who can influence what, under which knowledge and access conditions. Attack Taxonomy describes the mechanism vocabulary and its limits.

Assessment Methodology defines how to scope, test, interpret and report an assessment. Domain Profiles applies the common method to candidate system classes without inventing sector-wide thresholds. Vulnerability Registry specifies evidence records and a proposed review process. Relationship to Existing Frameworks records source-qualified mappings. Versioning and Identifiers controls citation and migration. Future defines research questions and triggers for revision. This Vision document states the purpose and the claims the project is prepared to make.

The worked examples accompany the specification as unexecuted teaching cases. Machine-readable definitions and record validation support consistent documentation. They are not an attack scanner or evidence that a vulnerability exists. A website and presentation communicate this same material and should never imply greater maturity than the underlying evidence supports.

## Evidence required for the next release

The architecture should be evaluated on a declared case population spanning different functions, lifecycle stages and consequence scopes. A development set can help clarify definitions. A separate held-out set, classified under frozen definitions by independent reviewers, can test whether those clarifications generalise. Reports should include uncertainty, disagreement, ambiguous cases, unrepresented cases and the effort required to produce a useful classification.

Comparative studies should test concrete questions, such as whether reviewers identify missing action-authorisation checks more consistently or trace a shared-resource failure more accurately. A comparison should use comparable information and task conditions. It should not score competitors by whether their documents happen to use the OSAFIS layer names.

Assessment usefulness requires its own evaluation. Teams should examine whether the method produces reproducible contracts and controls that address the observed failure while preserving authorised utility. They should track unsuccessful mitigation attempts and newly introduced failure modes. Human-facing studies require appropriate participant protections. Physical or irreversible effects require a safe test environment and explicit operational authority.

## Governance and publication

The project needs a named maintainer, a documented review process, conflict-of-interest handling and an appeal route before it represents a registry as independently governed. A proposed role is not an appointed reviewer. A proposed publication licence is not an adopted licence. Until the owner makes those decisions, the material should describe the intended open-reference direction without granting unspecified rights or claiming institutional endorsement.

Success would mean that independent users can apply, challenge and improve the representation, and that its assessments support better security decisions in specified settings. Establishing that result requires evidence beyond completing the documents. This specification makes the commitments and tests explicit so the project can pursue that evidence.