Published

Deployed System

vr.wm-sft-002 · wm-sft-002-deployed-system

Describe one operator-governed logical software system, its organizational use and evidence-qualified operational context.

World Models Information and virtual systems INF.SFT.SYS

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 12 layers · 12 findings · 48 questions

System identity Persist a logical operator-governed system across replacement instances.

Continuity and names

An operator assigns one system identity with scoped aliases. Product names, catalog UIDs and runtime instance identifiers are not interchangeable masters.

Stable system identity

An operator assigns one system identity with scoped aliases. Product names, catalog UIDs and runtime instance identifiers are not interchangeable masters.

Which authoritative inventory identifier and namespace identify this logical system? identity
Which system class and business purpose distinguish it from a product or runtime instance? classification
Which catalog and telemetry aliases map to this system, with what scope and ambiguity? interoperability
Which identity rule applies when this system is renamed, split, merged or transferred? lifecycle

Purpose and boundary

The local record states the system purpose and boundary. A business grouping, authorization boundary and hosting boundary can differ and must be related explicitly.

Operational subject boundary

The local record states the system purpose and boundary. A business grouping, authorization boundary and hosting boundary can differ and must be related explicitly.

What capability does this system provide to its intended users? definition
Which externally mastered components belong to the system boundary at the stated time? composition
Where does the logical boundary differ from the security authorization boundary? constraint
How are shared services and outsourced parts represented without assigning their masters to this system? exception

Accountability and usage Separate accountability, authorization and organizational use.

Accountability assignments

The accountable operator, custodian and decision authority are role references with scope and time. A catalog owner label alone grants no permission.

Time-qualified accountability

The accountable operator, custodian and decision authority are role references with scope and time. A catalog owner label alone grants no permission.

Which role is accountable for the system during each effective interval? ownership
Which authority reference permits approval of a system boundary or lifecycle assertion? authority
How are producer, operator, service custodian and using organization distinguished? relationship
What escalation applies when ownership is absent, overlapping or disputed? exception

Organizational usage

Usage assertions connect a logical system to organization, purpose and information categories. They neither authorize processing nor require a separate system per tenant.

Effective-dated use context

Usage assertions connect a logical system to organization, purpose and information categories. They neither authorize processing nor require a separate system per tenant.

Which organizations or tenant scopes use this system for which purpose? relationship
When was a usage assertion effective and when was it recorded? temporal
Which information-category and data-governance references constrain this use? privacy
What evidence distinguishes shared tenancy, a separate operator system and an unknown usage claim? exception

Composition and operation references Bind external masters without importing their lifecycle or execution.

Product and release realization

A system can realize several products and releases, including custom software. Bindings separate intended, approved and observed realization and allow simultaneous versions.

Realization references

A system can realize several products and releases, including custom software. Bindings separate intended, approved and observed realization and allow simultaneous versions.

Which product, component and release masters realize this system capability? composition
Which realization bindings are intended, approved, observed or no longer applicable? state
What deployment occurrence or inventory observation supports each running-version assertion? evidence
How are partial rollout, rollback and conflicting version observations retained? exception

Runtime and interface context

Runtime, endpoint and API references locate an operational realization. The local system neither controls orchestration nor owns network addresses or interface schemas.

Runtime and exposure references

Runtime, endpoint and API references locate an operational realization. The local system neither controls orchestration nor owns network addresses or interface schemas.

Which runtime environment references and location claims apply to this system scope? spatial
Which API and endpoint masters expose or connect this system? relationship
How are ephemeral runtime instances correlated without replacing the system master identifier? identity
Which placement or connectivity restrictions apply and where is compliance evaluated? constraint

Lifecycle and approved context Keep local lifecycle assertions distinct from operational actions and baseline execution.

System lifecycle assertions

The logical system can be planned, active, suspended or retired under an adopting profile. These are proposed local terms; shutdown, migration and reactivation are separate authorized processes.

Lifecycle evidence

The logical system can be planned, active, suspended or retired under an adopting profile. These are proposed local terms; shutdown, migration and reactivation are separate authorized processes.

Which local lifecycle state is asserted and which profile defines it? state
What approved decision and external operation evidence justify the stated transition? process
How does retirement of the logical system relate to remaining runtime and consumer bindings? temporal
When can a suspended or retired identity be resumed rather than replaced? exception

Approved context and deviations

Approved system context is referenced by immutable revision. Detailed configurations and change requests remain externally mastered; differences are evidence claims rather than execution instructions.

Baseline and deviation references

Which approved configuration baseline revision applies to this system scope? requirement
Which external comparison identifies a difference between the baseline and an observation? quality
What exception decision qualifies acceptance of an identified deviation? authority
What change-control reference supersedes a baseline without rewriting past observations? validation

Recognition and assurance context Represent evidence and limits of operational assertions.

Recognition and observation

Recognition uses explicit identity correlations and observation scope. An absent signal is not proof of absence; a health sample does not certify the entire system.

Evidence-qualified recognition

Recognition uses explicit identity correlations and observation scope. An absent signal is not proof of absence; a health sample does not certify the entire system.

Which observer and source record produced this system-state assertion? provenance
Which metric definition, unit, window and population qualify the reported measurement? measurement
When does an observation become stale or contradictory under the selected profile? quality
What matching evidence prevents an unrelated instance from being attributed to this system? validation

Impact and assurance references

Business criticality, reliability commitments and assurance decisions are separately scoped assertions. A designation or successful check does not establish overall safety, security or compliance.

Criticality and assurance context

Business criticality, reliability commitments and assurance decisions are separately scoped assertions. A designation or successful check does not establish overall safety, security or compliance.

Which business impact or criticality assessment applies to this system? classification
Which reliability commitment and recovery policy references apply to the stated use? requirement
Which security assessment or unresolved advisory references affect this system context? security
Who accepted a qualified assurance conclusion and what limits or expiry apply? decision

Record continuity and interoperability Preserve traceability and controlled exchange for this model records.

Record provenance and retention

Local assertions retain revisions and source links according to retention policy. Minimal lawful tombstones can preserve identity after payload disposal; retirement is not erasure.

Evidence and disposition context

Local assertions retain revisions and source links according to retention policy. Minimal lawful tombstones can preserve identity after payload disposal; retirement is not erasure.

Which source and revision history support this system-record revision? provenance
Which recipient view can disclose inventory, topology or assurance evidence? access
Which retention schedule and scoped holds govern this record and its artifacts? retention
What minimal continuity evidence remains after authorized record disposal? lifecycle

Profiles and interchange

Catalog, telemetry and security-plan projections use explicit versioned mappings. Similar labels are not identity equivalence, runtime permissions or conformance evidence.

Versioned model bindings

Catalog, telemetry and security-plan projections use explicit versioned mappings. Similar labels are not identity equivalence, runtime permissions or conformance evidence.

Which profile maps this system record into a catalog or security-plan representation? interoperability
Which meanings or values are lost or narrowed in the selected projection? constraint
Which conformance result and fixture set support this mapping version? validation
How are unmapped legacy N4 fields and unresolved neighbor references handled? exception

Classifiers Filled

Family: World Models
Category: Information and virtual systems
Entry kind: entity
Navigation path: NAV.INF.SFT.SYS
Domain: INF.SFT.SYS
Industry: Cross-industry
Tags: deployedsysteminf.sft.sys
Also called: N4

What it is Filled

The queue label Deployed System refers to the persistent logical subject named Software System / Business Application in the current registry. One system identity persists across deployments, scaling and replacement instances. Planning and retirement records are allowed without a currently running instance. The owner archetype is the accountable operator, not necessarily the producer. This is proposed research structure, not an operational control plane.

In scope

Logical system identity, purpose, capability limits and time-qualified operator and usage bindings
System-specific membership, realization, environment, API and endpoint references
Local lifecycle assertions, approved-context references, recognition evidence, assurance context and record continuity

Out of scope

Product, component, release, license, SBOM, vulnerability, organization and authority master lifecycles
Deployment execution, runtime orchestration, endpoint administration, configuration application, telemetry collection and reliability computation
Business payload storage, credential storage, legal compliance determination and security enforcement

Why it exists Filled

Describe one operator-governed logical software system, its organizational use and evidence-qualified operational context.

Distinguishing features Derived, awaiting review

Unlike WM-SFT-001 Software Product: Product offering and producer lifecycle are externally mastered. A product or release name does not identify an operator system.
Unlike WM-SFT-009 Deployment: Deployment occurrences and activation evidence are referenced; rollout, rollback and decommission execution are not owned here.
Unlike WM-SFT-010 Runtime / Compute Environment: Hosting topology and instance lifecycle remain runtime-owned. A system can span multiple environments and outlive instances.
Unlike WM-ORG-001 Organization: Organizations and their authority are separate masters; only system-specific role and usage bindings are recorded here.
Unlike WM-SFT-018 Network / Endpoint: Endpoints reference the exposed system; addresses, reachability and endpoint lifecycle remain endpoint-owned.
Unlike WM-SFT-007 Software Component / Package: Component identity and package metadata remain component-owned; logical membership alone is local context.
Unlike WM-SFT-008 Build / Release: Release and build identity, provenance and distribution are external. Concurrent release references are permitted.
Unlike WM-SFT-003 API / Interface Contract: API definitions and interface lifecycle are external; system provider and consumer roles are local bindings.
Unlike WM-SFT-011 Software Configuration: Configuration content, evaluation and application are external; baseline applicability and evidence references are local.
Unlike WM-SFT-016 Service Level Objective / Reliability Commitment: Commitment definitions, calculation and evaluation stay external; applicability is recorded here.
Unlike WM-SFT-017 Telemetry / Operational Signal: Observation payloads, signal collection and evaluation stay external; this system records qualified evidence links.
Unlike Shared legacy N4 and unreviewed legacy supplement: Split the combined product-and-system boundary. Preserve system purpose, operator and realization references; do not copy product publishing, dependency analysis, environment execution, broad conformance assertions or wildcard imports. Physical size and mass are inapplicable to the logical root; measured operational properties require metric context.

Note: Derived from boundary notes against neighbouring models.

What robots and AI may and may not do Derived, awaiting review

Must not

Default deny for inventory and topology disclosure; recipient views follow purpose, classification and authoritative access decisions.
Never store credentials, private keys, personal user lists or business payload in a system context record.
Actual erasure and decommission execution belong to the adopting-Dimension disposition service and deployment/runtime masters; never cascade-delete referenced products, environments or organizational records.
Deny unless an authoritative policy decision permits the subject, action, purpose and recipient view; catalog ownership is metadata only.

May

Register system context: Proposed, unimplemented local function. Create a proposed local system identity record after duplicate and boundary review.
Record usage assignment: Proposed, unimplemented local function. Record an effective-dated system usage or responsibility assertion.
Bind realization evidence: Proposed, unimplemented local function. Link externally mastered release, deployment and environment evidence to the system.
Record lifecycle assertion: Proposed, unimplemented local function. Record a justified system lifecycle assertion under an adopted profile.
Attach observation context: Proposed, unimplemented local function. Associate an evidence reference with a bounded system observation.
Project permitted context: Proposed, unimplemented local function. Produce a permitted local view through a pinned mapping profile.

Note: Derived from functions, policies, CRUD and access rules; prohibitions were not authored for agents as such.

Moral aspects Derived, awaiting review

Restricted or dangerous applications are described only by policy, authority and risk references; no operational harmful guidance.
Log denials, access expansion and exports without copying secrets or excessive personal data.

Note: Sentences mentioning harm, privacy, consent or similar, collected from the specification.

Owners Filled

Steward

Accountable operator role and organizational authority references; no fixed company owner

Roles

Accountable operator: Own the logical system boundary and assign accountable roles under organizational authority.
System record steward: Maintain local identity, mappings, revisions and explicit unknowns.
Evidence custodian: Resolve protected evidence references and retention rules without changing external findings.
Assurance reviewer: Review criticality, boundary and conclusion scope; do not infer authority from catalog ownership.
Authorized reader: Use only the permitted recipient view and preserve qualifications.

Links to other meta-models Filled

references

WM-SFT-001 - Product offering and producer lifecycle are externally mastered. A product or release name does not identify an operator system. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-009 - Deployment occurrences and activation evidence are referenced; rollout, rollback and decommission execution are not owned here. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-010 - Hosting topology and instance lifecycle remain runtime-owned. A system can span multiple environments and outlive instances. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-ORG-001 - Organizations and their authority are separate masters; only system-specific role and usage bindings are recorded here. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-018 - Endpoints reference the exposed system; addresses, reachability and endpoint lifecycle remain endpoint-owned. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-007 - Component identity and package metadata remain component-owned; logical membership alone is local context. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-008 - Release and build identity, provenance and distribution are external. Concurrent release references are permitted. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-003 - API definitions and interface lifecycle are external; system provider and consumer roles are local bindings. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-011 - Configuration content, evaluation and application are external; baseline applicability and evidence references are local. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-016 - Commitment definitions, calculation and evaluation stay external; applicability is recorded here. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.
WM-SFT-017 - Observation payloads, signal collection and evaluation stay external; this system records qualified evidence links. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning.

neighbor

WM-SFT-001 Software Product - Product offering and producer lifecycle are externally mastered. A product or release name does not identify an operator system.
WM-SFT-009 Deployment - Deployment occurrences and activation evidence are referenced; rollout, rollback and decommission execution are not owned here.
WM-SFT-010 Runtime / Compute Environment - Hosting topology and instance lifecycle remain runtime-owned. A system can span multiple environments and outlive instances.
WM-ORG-001 Organization - Organizations and their authority are separate masters; only system-specific role and usage bindings are recorded here.
WM-SFT-018 Network / Endpoint - Endpoints reference the exposed system; addresses, reachability and endpoint lifecycle remain endpoint-owned.
WM-SFT-007 Software Component / Package - Component identity and package metadata remain component-owned; logical membership alone is local context.
WM-SFT-008 Build / Release - Release and build identity, provenance and distribution are external. Concurrent release references are permitted.
WM-SFT-003 API / Interface Contract - API definitions and interface lifecycle are external; system provider and consumer roles are local bindings.
WM-SFT-011 Software Configuration - Configuration content, evaluation and application are external; baseline applicability and evidence references are local.
WM-SFT-016 Service Level Objective / Reliability Commitment - Commitment definitions, calculation and evaluation stay external; applicability is recorded here.
WM-SFT-017 Telemetry / Operational Signal - Observation payloads, signal collection and evaluation stay external; this system records qualified evidence links.
Shared legacy N4 and unreviewed legacy supplement - Split the combined product-and-system boundary. Preserve system purpose, operator and realization references; do not copy product publishing, dependency analysis, environment execution, broad conformance assertions or wildcard imports. Physical size and mass are inapplicable to the logical root; measured operational properties require metric context.

What else AI and robots need to interact with it Incomplete

Sources Filled

Descriptor Format of Catalog Entities - Cloud Native Computing Foundation
Guide for Security-Focused Configuration Management of Information Systems - National Institute of Standards and Technology
Service semantic conventions - Cloud Native Computing Foundation
Objects In Kubernetes - Cloud Native Computing Foundation
PROV-O: The PROV Ontology - World Wide Web Consortium
OSCAL System Security Plan Model v1.1.3 JSON Format Reference - National Institute of Standards and Technology
Date and Time on the Internet: Timestamps - Internet Engineering Task Force

Open questions

Pin and verify source versions, claim support, licenses and target implementation schemas, then restore independent external provider review before canonical promotion.
Build adoption profiles for shared tenancy, outsourced operation, identity split/merge, organizational transfer, ambiguous release masters, retirement with residual runtimes and lawful disposition.
Implement nested schemas and test versioned mappings with concurrent versions, stale or conflicting observations, permission denial, unknown placement, redacted export and loss of reference resolution.
Executable nested schemas, API bindings and adversarial instance fixtures are incomplete.
Cross-organization identity federation, outsourced-service contracts and sector-specific authority require adoption profiles.
Current documentation release pins, licensing and independent source verification remain open.
No independent external provider review.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-002-deployed-system/spec.yaml