{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-sft-002","code":"wm-sft-002-deployed-system","url":"https://ver.cy/models/wm-sft-002-deployed-system/","name":"Deployed System","alternateNames":["N4"],"kind":"world-model","status":"published","version":"1.0.0-reviewable-draft","language":"en","classifiers":{"family":"World Models","category":"Information and virtual systems","entryKind":"entity","plane":"","domain":["INF.SFT.SYS"],"industry":["Cross-industry"],"navPath":"NAV.INF.SFT.SYS","tags":["deployed","system","inf.sft.sys"],"facets":{}},"whatItIs":"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.","purpose":"Describe one operator-governed logical software system, its organizational use and evidence-qualified operational context.","scope":{"in":["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":["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"],"boundaries":[{"neighbor":"WM-SFT-001 Software Product","distinction":"Product offering and producer lifecycle are externally mastered. A product or release name does not identify an operator system."},{"neighbor":"WM-SFT-009 Deployment","distinction":"Deployment occurrences and activation evidence are referenced; rollout, rollback and decommission execution are not owned here."},{"neighbor":"WM-SFT-010 Runtime / Compute Environment","distinction":"Hosting topology and instance lifecycle remain runtime-owned. A system can span multiple environments and outlive instances."},{"neighbor":"WM-ORG-001 Organization","distinction":"Organizations and their authority are separate masters; only system-specific role and usage bindings are recorded here."},{"neighbor":"WM-SFT-018 Network / Endpoint","distinction":"Endpoints reference the exposed system; addresses, reachability and endpoint lifecycle remain endpoint-owned."},{"neighbor":"WM-SFT-007 Software Component / Package","distinction":"Component identity and package metadata remain component-owned; logical membership alone is local context."},{"neighbor":"WM-SFT-008 Build / Release","distinction":"Release and build identity, provenance and distribution are external. Concurrent release references are permitted."},{"neighbor":"WM-SFT-003 API / Interface Contract","distinction":"API definitions and interface lifecycle are external; system provider and consumer roles are local bindings."},{"neighbor":"WM-SFT-011 Software Configuration","distinction":"Configuration content, evaluation and application are external; baseline applicability and evidence references are local."},{"neighbor":"WM-SFT-016 Service Level Objective / Reliability Commitment","distinction":"Commitment definitions, calculation and evaluation stay external; applicability is recorded here."},{"neighbor":"WM-SFT-017 Telemetry / Operational Signal","distinction":"Observation payloads, signal collection and evaluation stay external; this system records qualified evidence links."},{"neighbor":"Shared legacy N4 and unreviewed legacy supplement","distinction":"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."}]},"distinguishingFeatures":["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."],"structure":{"bundles":[{"id":"bundle-identity","name":"System identity","description":"Persist a logical operator-governed system across replacement instances.","layers":[{"id":"layer-identity","name":"Continuity and names","description":"An operator assigns one system identity with scoped aliases. Product names, catalog UIDs and runtime instance identifiers are not interchangeable masters.","findings":[{"id":"system-identity","name":"Stable system identity","description":"An operator assigns one system identity with scoped aliases. Product names, catalog UIDs and runtime instance identifiers are not interchangeable masters.","questions":[{"text":"Which authoritative inventory identifier and namespace identify this logical system?","id":"system-identity-q01","kind":"identity"},{"text":"Which system class and business purpose distinguish it from a product or runtime instance?","id":"system-identity-q02","kind":"classification"},{"text":"Which catalog and telemetry aliases map to this system, with what scope and ambiguity?","id":"system-identity-q03","kind":"interoperability"},{"text":"Which identity rule applies when this system is renamed, split, merged or transferred?","id":"system-identity-q04","kind":"lifecycle"}]}]},{"id":"layer-boundary","name":"Purpose and boundary","description":"The local record states the system purpose and boundary. A business grouping, authorization boundary and hosting boundary can differ and must be related explicitly.","findings":[{"id":"system-boundary","name":"Operational subject boundary","description":"The local record states the system purpose and boundary. A business grouping, authorization boundary and hosting boundary can differ and must be related explicitly.","questions":[{"text":"What capability does this system provide to its intended users?","id":"system-boundary-q01","kind":"definition"},{"text":"Which externally mastered components belong to the system boundary at the stated time?","id":"system-boundary-q02","kind":"composition"},{"text":"Where does the logical boundary differ from the security authorization boundary?","id":"system-boundary-q03","kind":"constraint"},{"text":"How are shared services and outsourced parts represented without assigning their masters to this system?","id":"system-boundary-q04","kind":"exception"}]}]}]},{"id":"bundle-governance","name":"Accountability and usage","description":"Separate accountability, authorization and organizational use.","layers":[{"id":"layer-responsibility","name":"Accountability assignments","description":"The accountable operator, custodian and decision authority are role references with scope and time. A catalog owner label alone grants no permission.","findings":[{"id":"system-accountability","name":"Time-qualified accountability","description":"The accountable operator, custodian and decision authority are role references with scope and time. A catalog owner label alone grants no permission.","questions":[{"text":"Which role is accountable for the system during each effective interval?","id":"system-accountability-q01","kind":"ownership"},{"text":"Which authority reference permits approval of a system boundary or lifecycle assertion?","id":"system-accountability-q02","kind":"authority"},{"text":"How are producer, operator, service custodian and using organization distinguished?","id":"system-accountability-q03","kind":"relationship"},{"text":"What escalation applies when ownership is absent, overlapping or disputed?","id":"system-accountability-q04","kind":"exception"}]}]},{"id":"layer-usage","name":"Organizational usage","description":"Usage assertions connect a logical system to organization, purpose and information categories. They neither authorize processing nor require a separate system per tenant.","findings":[{"id":"system-usage","name":"Effective-dated use context","description":"Usage assertions connect a logical system to organization, purpose and information categories. They neither authorize processing nor require a separate system per tenant.","questions":[{"text":"Which organizations or tenant scopes use this system for which purpose?","id":"system-usage-q01","kind":"relationship"},{"text":"When was a usage assertion effective and when was it recorded?","id":"system-usage-q02","kind":"temporal"},{"text":"Which information-category and data-governance references constrain this use?","id":"system-usage-q03","kind":"privacy"},{"text":"What evidence distinguishes shared tenancy, a separate operator system and an unknown usage claim?","id":"system-usage-q04","kind":"exception"}]}]}]},{"id":"bundle-bindings","name":"Composition and operation references","description":"Bind external masters without importing their lifecycle or execution.","layers":[{"id":"layer-realization","name":"Product and release realization","description":"A system can realize several products and releases, including custom software. Bindings separate intended, approved and observed realization and allow simultaneous versions.","findings":[{"id":"system-realization","name":"Realization references","description":"A system can realize several products and releases, including custom software. Bindings separate intended, approved and observed realization and allow simultaneous versions.","questions":[{"text":"Which product, component and release masters realize this system capability?","id":"system-realization-q01","kind":"composition"},{"text":"Which realization bindings are intended, approved, observed or no longer applicable?","id":"system-realization-q02","kind":"state"},{"text":"What deployment occurrence or inventory observation supports each running-version assertion?","id":"system-realization-q03","kind":"evidence"},{"text":"How are partial rollout, rollback and conflicting version observations retained?","id":"system-realization-q04","kind":"exception"}]}]},{"id":"layer-environment","name":"Runtime and interface context","description":"Runtime, endpoint and API references locate an operational realization. The local system neither controls orchestration nor owns network addresses or interface schemas.","findings":[{"id":"system-runtime-context","name":"Runtime and exposure references","description":"Runtime, endpoint and API references locate an operational realization. The local system neither controls orchestration nor owns network addresses or interface schemas.","questions":[{"text":"Which runtime environment references and location claims apply to this system scope?","id":"system-runtime-context-q01","kind":"spatial"},{"text":"Which API and endpoint masters expose or connect this system?","id":"system-runtime-context-q02","kind":"relationship"},{"text":"How are ephemeral runtime instances correlated without replacing the system master identifier?","id":"system-runtime-context-q03","kind":"identity"},{"text":"Which placement or connectivity restrictions apply and where is compliance evaluated?","id":"system-runtime-context-q04","kind":"constraint"}]}]}]},{"id":"bundle-lifecycle","name":"Lifecycle and approved context","description":"Keep local lifecycle assertions distinct from operational actions and baseline execution.","layers":[{"id":"layer-state","name":"System lifecycle assertions","description":"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.","findings":[{"id":"system-lifecycle","name":"Lifecycle evidence","description":"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.","questions":[{"text":"Which local lifecycle state is asserted and which profile defines it?","id":"system-lifecycle-q01","kind":"state"},{"text":"What approved decision and external operation evidence justify the stated transition?","id":"system-lifecycle-q02","kind":"process"},{"text":"How does retirement of the logical system relate to remaining runtime and consumer bindings?","id":"system-lifecycle-q03","kind":"temporal"},{"text":"When can a suspended or retired identity be resumed rather than replaced?","id":"system-lifecycle-q04","kind":"exception"}]}]},{"id":"layer-baseline","name":"Approved context and deviations","description":"Approved system context is referenced by immutable revision. Detailed configurations and change requests remain externally mastered; differences are evidence claims rather than execution instructions.","findings":[{"id":"system-baseline","name":"Baseline and deviation references","description":"Approved system context is referenced by immutable revision. Detailed configurations and change requests remain externally mastered; differences are evidence claims rather than execution instructions.","questions":[{"text":"Which approved configuration baseline revision applies to this system scope?","id":"system-baseline-q01","kind":"requirement"},{"text":"Which external comparison identifies a difference between the baseline and an observation?","id":"system-baseline-q02","kind":"quality"},{"text":"What exception decision qualifies acceptance of an identified deviation?","id":"system-baseline-q03","kind":"authority"},{"text":"What change-control reference supersedes a baseline without rewriting past observations?","id":"system-baseline-q04","kind":"validation"}]}]}]},{"id":"bundle-assurance","name":"Recognition and assurance context","description":"Represent evidence and limits of operational assertions.","layers":[{"id":"layer-observation","name":"Recognition and observation","description":"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.","findings":[{"id":"system-observation","name":"Evidence-qualified recognition","description":"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.","questions":[{"text":"Which observer and source record produced this system-state assertion?","id":"system-observation-q01","kind":"provenance"},{"text":"Which metric definition, unit, window and population qualify the reported measurement?","id":"system-observation-q02","kind":"measurement"},{"text":"When does an observation become stale or contradictory under the selected profile?","id":"system-observation-q03","kind":"quality"},{"text":"What matching evidence prevents an unrelated instance from being attributed to this system?","id":"system-observation-q04","kind":"validation"}]}]},{"id":"layer-commitments","name":"Impact and assurance references","description":"Business criticality, reliability commitments and assurance decisions are separately scoped assertions. A designation or successful check does not establish overall safety, security or compliance.","findings":[{"id":"system-assurance","name":"Criticality and assurance context","description":"Business criticality, reliability commitments and assurance decisions are separately scoped assertions. A designation or successful check does not establish overall safety, security or compliance.","questions":[{"text":"Which business impact or criticality assessment applies to this system?","id":"system-assurance-q01","kind":"classification"},{"text":"Which reliability commitment and recovery policy references apply to the stated use?","id":"system-assurance-q02","kind":"requirement"},{"text":"Which security assessment or unresolved advisory references affect this system context?","id":"system-assurance-q03","kind":"security"},{"text":"Who accepted a qualified assurance conclusion and what limits or expiry apply?","id":"system-assurance-q04","kind":"decision"}]}]}]},{"id":"bundle-continuity","name":"Record continuity and interoperability","description":"Preserve traceability and controlled exchange for this model records.","layers":[{"id":"layer-evidence","name":"Record provenance and retention","description":"Local assertions retain revisions and source links according to retention policy. Minimal lawful tombstones can preserve identity after payload disposal; retirement is not erasure.","findings":[{"id":"system-record-continuity","name":"Evidence and disposition context","description":"Local assertions retain revisions and source links according to retention policy. Minimal lawful tombstones can preserve identity after payload disposal; retirement is not erasure.","questions":[{"text":"Which source and revision history support this system-record revision?","id":"system-record-continuity-q01","kind":"provenance"},{"text":"Which recipient view can disclose inventory, topology or assurance evidence?","id":"system-record-continuity-q02","kind":"access"},{"text":"Which retention schedule and scoped holds govern this record and its artifacts?","id":"system-record-continuity-q03","kind":"retention"},{"text":"What minimal continuity evidence remains after authorized record disposal?","id":"system-record-continuity-q04","kind":"lifecycle"}]}]},{"id":"layer-mapping","name":"Profiles and interchange","description":"Catalog, telemetry and security-plan projections use explicit versioned mappings. Similar labels are not identity equivalence, runtime permissions or conformance evidence.","findings":[{"id":"system-interoperability","name":"Versioned model bindings","description":"Catalog, telemetry and security-plan projections use explicit versioned mappings. Similar labels are not identity equivalence, runtime permissions or conformance evidence.","questions":[{"text":"Which profile maps this system record into a catalog or security-plan representation?","id":"system-interoperability-q01","kind":"interoperability"},{"text":"Which meanings or values are lost or narrowed in the selected projection?","id":"system-interoperability-q02","kind":"constraint"},{"text":"Which conformance result and fixture set support this mapping version?","id":"system-interoperability-q03","kind":"validation"},{"text":"How are unmapped legacy N4 fields and unresolved neighbor references handled?","id":"system-interoperability-q04","kind":"exception"}]}]}]}]},"agentConduct":{"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."],"mustNot":["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."],"requiresHuman":[]},"ethics":{"considerations":["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."],"affectedParties":[]},"owners":{"steward":"Accountable operator role and organizational authority references; no fixed company owner","roles":[{"name":"Accountable operator","responsibilities":["Own the logical system boundary and assign accountable roles under organizational authority."]},{"name":"System record steward","responsibilities":["Maintain local identity, mappings, revisions and explicit unknowns."]},{"name":"Evidence custodian","responsibilities":["Resolve protected evidence references and retention rules without changing external findings."]},{"name":"Assurance reviewer","responsibilities":["Review criticality, boundary and conclusion scope; do not infer authority from catalog ownership."]},{"name":"Authorized reader","responsibilities":["Use only the permitted recipient view and preserve qualifications."]}],"masterSystems":[]},"relations":[{"target":"WM-SFT-001","type":"references","note":"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."},{"target":"WM-SFT-009","type":"references","note":"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."},{"target":"WM-SFT-010","type":"references","note":"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."},{"target":"WM-ORG-001","type":"references","note":"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."},{"target":"WM-SFT-018","type":"references","note":"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."},{"target":"WM-SFT-007","type":"references","note":"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."},{"target":"WM-SFT-008","type":"references","note":"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."},{"target":"WM-SFT-003","type":"references","note":"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."},{"target":"WM-SFT-011","type":"references","note":"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."},{"target":"WM-SFT-016","type":"references","note":"Commitment definitions, calculation and evaluation stay external; applicability is recorded here. Registry edges are candidate bindings; added neighbors are proposed mappings needing version pinning."},{"target":"WM-SFT-017","type":"references","note":"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."},{"target":"WM-SFT-001 Software Product","type":"neighbor","note":"Product offering and producer lifecycle are externally mastered. A product or release name does not identify an operator system."},{"target":"WM-SFT-009 Deployment","type":"neighbor","note":"Deployment occurrences and activation evidence are referenced; rollout, rollback and decommission execution are not owned here."},{"target":"WM-SFT-010 Runtime / Compute Environment","type":"neighbor","note":"Hosting topology and instance lifecycle remain runtime-owned. A system can span multiple environments and outlive instances."},{"target":"WM-ORG-001 Organization","type":"neighbor","note":"Organizations and their authority are separate masters; only system-specific role and usage bindings are recorded here."},{"target":"WM-SFT-018 Network / Endpoint","type":"neighbor","note":"Endpoints reference the exposed system; addresses, reachability and endpoint lifecycle remain endpoint-owned."},{"target":"WM-SFT-007 Software Component / Package","type":"neighbor","note":"Component identity and package metadata remain component-owned; logical membership alone is local context."},{"target":"WM-SFT-008 Build / Release","type":"neighbor","note":"Release and build identity, provenance and distribution are external. Concurrent release references are permitted."},{"target":"WM-SFT-003 API / Interface Contract","type":"neighbor","note":"API definitions and interface lifecycle are external; system provider and consumer roles are local bindings."},{"target":"WM-SFT-011 Software Configuration","type":"neighbor","note":"Configuration content, evaluation and application are external; baseline applicability and evidence references are local."},{"target":"WM-SFT-016 Service Level Objective / Reliability Commitment","type":"neighbor","note":"Commitment definitions, calculation and evaluation stay external; applicability is recorded here."},{"target":"WM-SFT-017 Telemetry / Operational Signal","type":"neighbor","note":"Observation payloads, signal collection and evaluation stay external; this system records qualified evidence links."},{"target":"Shared legacy N4 and unreviewed legacy supplement","type":"neighbor","note":"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."}],"interaction":{"identity":{"applicability":"required","items":["Authoritative master-system identifier with issuer","Governed global identifier or IRI","Dimension-assigned UUID or ULID"]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":[]},"capabilities":{"applicability":"required","items":["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."]},"hazards":{"applicability":"optional","items":[]},"interfaces":{"applicability":"required","items":["PROV-O: The PROV Ontology"]},"context":{"applicability":"required","items":["NIST examples are qualified US federal guidance and OSCAL structure, not universal legal requirements.","Cloud-native sources illustrate selected implementations; non-container, on-premises and outsourced systems must map through an explicit profile."]}},"sources":[{"title":"Descriptor Format of Catalog Entities","url":"https://backstage.io/docs/features/software-catalog/descriptor-format/","note":"Cloud Native Computing Foundation"},{"title":"Guide for Security-Focused Configuration Management of Information Systems","url":"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-128.pdf","note":"National Institute of Standards and Technology"},{"title":"Service semantic conventions","url":"https://opentelemetry.io/docs/specs/semconv/resource/service/","note":"Cloud Native Computing Foundation"},{"title":"Objects In Kubernetes","url":"https://kubernetes.io/docs/concepts/overview/working-with-objects/","note":"Cloud Native Computing Foundation"},{"title":"PROV-O: The PROV Ontology","url":"https://www.w3.org/TR/prov-o/","note":"World Wide Web Consortium"},{"title":"OSCAL System Security Plan Model v1.1.3 JSON Format Reference","url":"https://pages.nist.gov/OSCAL-Reference/models/v1.1.3/system-security-plan/json-reference/","note":"National Institute of Standards and Technology"},{"title":"Date and Time on the Internet: Timestamps","url":"https://www.rfc-editor.org/rfc/rfc3339.html","note":"Internet Engineering Task Force"}],"openQuestions":["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."],"resources":{"spec":"/models/wm-sft-002-deployed-system/spec.yaml","agents":"/models/wm-sft-002-deployed-system/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-sft-002"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-sft-002-deployed-system/spec.yaml"],"providers":["Codex"],"researchStatus":"reviewable-draft","generatedAt":"2026-10-06T17:27:04Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"derived","structure":"filled","agentConduct":"derived","ethics":"derived","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"missing","interaction.capabilities":"filled","interaction.hazards":"missing","interaction.interfaces":"derived","interaction.context":"filled","sources":"filled"},"notes":{"distinguishingFeatures":"Derived from boundary notes against neighbouring models.","agentConduct":"Derived from functions, policies, CRUD and access rules; prohibitions were not authored for agents as such.","ethics":"Sentences mentioning harm, privacy, consent or similar, collected from the specification.","interaction.properties":"Institutional or informational subject: no invented physical properties."},"score":0.75}}