7lens Data Model — Technology

Canonical copy

Copied from the 7lens app repository, docs/datamodel/7lens-data-model-technology.md at 012d434, on 2026-11-11. Document version 1.0, dated 2026-10-30. The app repository is the source of truth. Do not edit this page here; change the source and re-run npm run sync:reference.

This is a strategic source document: the Technology catalog and the Asset model the catalog recognizes. An Asset belongs to one or more Applications and/or Platforms. It maps to Technology through its Asset Type and one Offering of that same Service.

---

Purpose

The 7lens Technology model is the catalog of technology capabilities the enterprise provides, and the Asset Types that say what a real instance of those capabilities is. After onboarding, the 7lens Technology axis is the authority for Stacks, Services, and Offerings. OSM is the narrow onboarding catalog. There is no per-entry link between a 7lens row and an OSM row. The two evolve in parallel. OSM does not own the declaration language, Platforms, Groups, adoption, or Asset Types.

Assets are not an axis. An Asset is an instance of one Asset Type in Inventory. Inventory is one document, inventory_schema_version: 2.

This document defines:

1. Catalog semantics — Stack, Service, Offering, and the cross-cutting Platform and ICT Provider.
2. Recognition — Asset Type under one Service, and the Asset that names that type and one Offering.
3. Declaration shape — how a characteristic or an Asset Type attribute is described, with the value kept outside the declaration.

Starter-pack contents are not rules. A number, a shared Domain, or a renamed Offering in a pack is data for that pack. It does not become a required characteristic or a required id.

The declaration language, reserved prefixes, pinned vocabularies, UCUM units, time, money, people, and provenance are summarized here and specified in docs/datamodel/7lens-data-model-conventions.md. That conventions document is not part of this file.

Product copy uses Stack, Service, Offering, Asset Type, Asset, Platform, and ICT Provider as defined here. In Configuration UI, accountable_person is labelled Owner.

---

Concepts

Identity test

Classify a thing by the first match:

1. ICT Provider — the supplier.
2. Service — a capability several products could supply.
3. Offering — one product or variant that supplies a Service.
4. Platform — something the enterprise operates that supplies Services and that business users work in.
5. Asset — one real instance, of an Asset Type under its Service, naming one Offering of that Service.
6. Business Application — what business users use to run a business process.

Applications are not Services. A library or a product is not a Service and not an Offering. ERP modules are characteristics of the Platform, not Services. Infrastructure that applications consume has no Platform unless a platform team runs it as one.

An Application and a Platform have no link. A Platform supplies Services and may produce Assets. The relation between an Application and a Platform, when needed, is derived from Assets. Application consumes still addresses Services. Offerings are not direct targets of consumes.

Stack

Definition

A Stack is an operational competency domain that groups Services (for example Compute, Databases, Networking, Storage). It is not a catalogue of end-user products.

Stacks are recursive. A Stack may name another Stack as parent_stack. The parent chain must not cycle. Stack identity is the Stack id. Services point at that id through technology_stack. There is no technology-stack Group on Applications. A per-Stack ROI view walks the executor Asset’s Asset Type, then that type’s Service, then technology_stack, then parent Stacks. The split is calculated. It is not stored.

What a Stack is not

• Not a Service, an Offering, or a Platform.
• Not a Business Domain.
• Not a node in Organization → Region → … → Legal Entity.

---

Service

Definition

A Service is a provider-neutral capability that more than one product could supply. Offerings under it are the products. Asset Types under it are the kinds of instance that capability produces.

A Service has a stable identity independent of any one vendor product and independent of any one running Asset.

Identity

Attribute	Rule
id	Exactly two dot segments, <stack_segment>.<service_segment>. Each segment is snake_case.
name	Human-readable name.
description	What the capability is.
technology_stack	Id of the Stack this Service belongs to.
offerings	The list of Offerings. The key is offerings.
asset_types	The list of Asset Types. Sibling of offerings. Omitted when the Service has none yet.

technology_stack and the first id segment are both catalog ids. The reference is technology_stack. The id grammar does not add a third segment.

Characteristics

A Service may carry characteristics. Each characteristic is a declaration plus, beside it, the value for this Service. The declaration holds no value. See Declarations.

Commitments — lifecycle, support windows, recovery and availability targets, approved data classes — are definition facts on the Service or Offering. They are not posture. Posture values live only on Assets.

What a Service is not

• Not a Business Application, including ERP, CRM, HR, and ITSM. Those products, when the enterprise operates them, are Platforms. The business uses built on them are Business Applications.
• Not a library, a package, or a named product. Those are Offerings only when they are the product that supplies the Service, and a library is not that product. A software-component Asset points at the language-runtime Offering it runs on.
• Not an Asset Type and not an Asset.

---

Offering

Definition

An Offering is one product or variant that supplies a Service. Several Offerings may supply the same Service. Adding a provider is a change to Technology. Moving an Asset from one Offering to another keeps the Asset id and its history.

Generic Offerings cover Assets that have no vendor product. Their ids end in self_hosted or custom_built.

Identity and required fields

Attribute	On a new Offering
id	Exactly three dot segments. The first two equal the parent Service id. The last segment is snake_case.
name	Human-readable product name. Must not match the name of an Asset Type of the same Service.
description	Required.
providers	At least one ICT Provider id, unless the Offering id ends in self_hosted or custom_built.

An existing Offering that fails those requirements warns. The warning does not block save.

These are expected. Missing values warn and do not block save:

Attribute	Rule
lifecycle_state	draft, pilot, production, sunset, or retired.
adoption_status	approved, tolerated, or prohibited.
characteristics	Declaration plus configured_value, same language as the Service. An Offering may narrow a Service characteristic. It may not widen it.
provenance	Definition provenance. Optional. A missing block warns.

Price and contract terms stay off the Offering. Commercial agreements are the Contracts extension, which is a separate model.

A reference to an Offering from outside the Service uses the qualified form <service_id>/<offering_id>. On a Platform the published fields that hold these references are serviceIds and offeringIds. Those names stay until a versioned migration. New reference fields use *_id / *_ids.

What an Offering is not

• Not a Service, and not a second copy of the Service for each vendor.
• Not an Asset Type. The type sits on the Service. An Offering may add extension declarations only for genuine provider-specific fields.
• Not a price list and not a Contract.

---

Asset Type

Definition

An Asset Type is the recognition key for Assets of one Service. Every Service may publish Asset Types as a sibling of its Offerings. Each Asset Type belongs to exactly one Service.

The same everyday name on two Services is two Asset Types. automation is one type on devops.ci_cd and another on auto.workflow_orchestration. data_store is one type on storage.object_storage and another on data.vector_search.

Identity

Attribute	Rule
id	<service_id>.<segment>. The segment is one snake_case token and contains no further dot. The id does not add a stack prefix beyond the Service id. The id is immutable.
name	Human-readable name. Must not match an Offering name of the same Service.
description	What one instance of this type is.
template_id / template_version	Optional provenance of the marketplace template the type was taken from. Provenance only.
declarations	The attributes every Asset of this type carries. A declaration carries no value. The Asset stores the value inside attributes[].

An Asset Type used by no Lens warns. A Lens reference to a missing Asset Type or a missing attribute errors.

Marketplace scope

Scope is which types to model. It is not a field on the Asset. Segments below are snake_case.

P0, modelled and populated:

Asset Type id
appplatform.language_runtime.software_component
devops.source_control.code_repository
devops.ci_cd.automation
auto.workflow_orchestration.automation
ai.agent_runtime.ai_agent
ai.foundation_models.ai_model_deployment
ai.agent_tooling.agent_tool
identity.directory_idp.non_human_identity
storage.object_storage.data_store
data.vector_search.data_store

P1, structure only:

Asset Type id
devops.container_registry.container_image
compute.virtual_machines.compute_instance
compute.kubernetes.kubernetes_cluster
ops.service_desk.saas_tenant

Named and not modelled: container_workload, load_balancer, public_ip, dns_record, tls_certificate, secret, waf_policy, security_agent_enrollment, database_instance, network_segment, cloud_account, license_entitlement, monitoring_rule, itsm_queue, prompt_template, eval_suite.

One software-component Asset is one occurrence of a package, library, or runtime in one place. The same version in two repositories is two Assets. They share purl and cpe. Findings and status stay on the occurrence. The Asset Type is appplatform.language_runtime.software_component. The Offering is the language runtime that occurrence runs on. Views may group occurrences by purl.

What an Asset Type is not

• Not an Offering, and not a list of Offerings.
• Not a category, a profile, a tag, or a free technologyRef.
• Not a tier field on the Asset. P0 and P1 are build scope.

---

Asset

Definition

An Asset is one real instance of an Asset Type. Inventory is the authority for instances. 7lens is the authority for an Asset’s meaning: its type, belonging, Platforms, and declared attributes. When a source system exists, that system stays the authority for raw observed facts, and 7lens records the source of each fact.

Recognition and identity

Attribute	Rule
asset_id	Opaque. New ids minted by 7lens match ^a-[a-z0-9]{16}$. The id encodes no type, Offering, Stack, or category. Ids are not reused.
asset_type_id	Required. Must be an Asset Type configured on a Service. An unknown id is an error.
offering_id	Required. One Offering of the same Service as the Asset Type.
external_ids	Optional source-system keys, each { scheme, value }. Distinct from provenance source_record_id.

Stack, Service, and ICT Provider are derived. Stack and Service come from the Asset Type. The Provider comes from the Offering. They are not stored on the Asset.

There is no category, no profile, and no technologyRef. There is no tier field. Inventory v1 is not a second readable shape.

Belonging

Belonging is who the Asset is for. It is an Application, a Domain, or a Platform. It is never a person and never called Owner. A business belonging may name an Application and/or a Domain. A platform belonging names a Platform.

A missing belonging is a warning, not an error.

A shared Asset belongs to the Platform. An Asset made for one Business Application belongs to that Application, whether a Platform produced it or not. An Asset may have no producing Platform; that is valid. Producing every Asset through a Platform is the recommended target. Which Applications a shared Asset affects is derived from Assets and is not stored.

Accountability for a person walks the belonging record’s accountable_person (Application, otherwise Domain; the Platform when belonging is a Platform). The Asset stores no person.

Deployments

An Asset references the Deployments it belongs to on Business Applications or Platforms (deployment_refs). Each reference has a role:

Role	Meaning
runtime	What the Deployment runs on.
source	The code the Deployment is built from.

The closed roles are runtime and source. Membership of the Application or Platform derives from this link. An Asset with belonging and no Deployment reference warns. Deployments do not list Assets. Environment lives on Deployments only; Assets inherit it. An Application and a Platform have no direct link. An Asset belongs to a Deployment, and that Deployment belongs to an Application or a Platform, not both. References to missing Platforms, Deployments, or Assets are errors. Missing environments warn.

A Deployment is a named context: optional environments (sandbox, dev, pre, pro, decom), optional deployed_in, and optional entry_points. It is not a live runtime instance. A Platform Deployment uses that same shape.

Attributes

Every declared attribute on an Asset uses one envelope. There is no structural split between descriptive attributes and posture.

Field	Meaning
name	Declaration name.
value	The number or token for this Asset.
declaration_version	Declaration version in force when the value was recorded.
last_confirmed	When the value was last confirmed.
origin	observed, assessed, or derived.
provenance	Required when origin is assessed, derived, or from a different source than the Asset row. An observed attribute may omit it when it matches the Asset row’s provenance.

Write precedence, highest first:

1. Assessed — human judgment. An observed write does not overwrite it unless the assessment expires or an operator clears it.
2. Observed from the designated authoritative_source.
3. Observed with the latest timestamp.

A lower-precedence observation still updates last_seen_at. It does not change the active value. The expiry duration of an assessment is not set.

Posture is the observed, assessed, or derived state of one Asset. Declarations hold no values. Only Assets carry those values. Each change is kept as history. Findings and other events are evidence, stored as fact records outside Configuration. They are not a substitute for the attribute. Roll-ups and counters across Assets are views and are never stored.

A stored derived value documents how it is calculated from Asset attributes. Freshness and validation status are computed. They are not stored on the value.

Links

A reference whose target kind is fixed stays a named field (Asset Type, Offering, belonging, Deployment role, Application consumes, Service stack, providers, fact-record ids).

An Asset-to-Asset link is a relationship record: relationship_id, from_asset_id, to_asset_id, kind, valid_from, valid_to, provenance. The closed verb list is depends_on, contains, and uses. Customers may narrow which Asset Types use a verb. They may not add a verb. automates and built_from stay readable on existing rows and are not written again. Do not add authenticates_as, runs_on, member_of, or acts_on.

Agent reach is computed from uses links to the model and the tool, the tool’s operation effects, and the access grant on the machine identity. Observed change is the execution’s targets. model and permissionScopes stay readable and are not written again.

Facts, not counters

Findings, operational demands, and automation executions stay. Delivery requests and access grants are added. An execution has targets, each a resource plus an effect: read, create, update, delete, or execute. An access grant’s principal is a non_human_identity Asset.

MTTR, time to market, saved cost, execution duration, and execution counts are views. They are never stored. MTTR is the mean of recoveredAt minus createdAt over incidents in the period. Time to market is delivered_at minus requested_at on a delivery request. Saved cost is the Contract unit price times the demands in the period whose automation is full and that link to an execution. Existing record fields keep their published names. A metric observation is kept only for a number that cannot be computed (effort_avoided, estimated_impact, realized_impact). New writes reject mttr, delivery_lead_time, and ops_cost_savings. Measurement periods are half-open.

Lifecycle and history

Asset status is its own closed list. It is not Service lifecycle_state, and it is not a recognition key. Terminal states include retired and deleted. The full transition graph is not published. Existing rows that break a documented transition warn.

Deletion has three meanings. Configuration hard-remove is a confirmed catalog delete. Inventory marked_for_deletion is a cleanup queue when Configuration breaks links; the Configuration write is still allowed. Asset status retired or deleted is a terminal operating state. Those two stay independent of marked_for_deletion. Ids are not reused.

Asset value history keeps the value, origin provenance, last confirmed, and declaration version. Entries older than seven years (P7Y) may be purged when someone runs cleanup. The current value is never removed by that rule. Technology characteristic values have no value history; Configuration backup and the change log cover them. Raw ingest lifetime is separate.

What an Asset is not

• Not a Stack, Service, Offering, or Asset Type.
• Not a Deployment definition. A Deployment is defined context. An Asset may evidence it. Discovery does not silently create, delete, or overwrite Deployment definitions.
• Not a stored KPI.

---

Platform

Definition

A Platform is something the enterprise operates that supplies a Service and that business users work in. ERP, CRM, HR, ITSM, and similar products, when the enterprise operates them, are Platforms. The business uses built on them are Business Applications. The vendor remains an ICT Provider. This matches the identity test already in this file.

A Platform is cross-cutting. It is not a level of Stack → Service → Offering.

Required on a new Platform

Attribute	Rule
id	Stable id. Snake_case.
name	Human-readable name.
description	Required.
accountable_person	Owner. Shape below. Required.
sourcing_model	in_house, third_party, or joint.
delivery_model	saas, self_deployed, provider_hosted, or hybrid.

Missing Domain, Legal Entity, Deployments, or lifecycle_state warns and does not block save. Free-text accountable is not written on a new Platform.

sourcing_model and delivery_model are independent. in_house means the organization controls the product. third_party means an external party controls it. joint is shared product control. Co-development or hosting alone is not joint. saas is a provider-operated product the consumer configures and does not deploy. self_deployed means the organization deploys it into an environment it controls. provider_hosted means an external provider hosts it, and it is not standard SaaS. hybrid is materially different delivery arrangements for the same Platform, not several regions. Neither field is inferred from the other.

Platforms gain Domain, Legal Entity, and Deployments the way Business Applications do. A Platform Deployment is not a live runtime instance.

What a Platform is not

• Not an ICT Provider.
• Not a Business Application. Business-process uses of a Platform are Business Applications linked to it.
• Not an Asset Type and not an Asset. Assets may belong to it.

---

ICT Provider

Definition

An ICT Provider is a supplier a Service or Offering relies on (cloud, software, hardware, SaaS, a managed service, or an open-source community). Providers are cross-cutting. They are not a level of Stack → Service → Offering.

A Provider is referenced only through providers on a Service or an Offering. Contracts are a separate model.

Required fields

Attribute	Rule
id	Stable id. Snake_case.
name	Human-readable name.
type	hyperscaler, saas_vendor, software_vendor, hardware_vendor, managed_service_provider, or open_source_community.

An existing Provider with a missing or unknown type warns. A new write errors. A Provider has no Owner. substitutability is high, medium, low, or none. risk_level is critical, high, medium, or low. headquarters and each processing_locations entry are an ISO 3166-1 alpha-2 code in lowercase.

What an ICT Provider is not

• Not a Platform.
• Not a Group target. Group rules do not use provider.
• Not a person and not an accountable_person.

---

Declarations

One declaration language lives in @7lens/contracts. It is used for Service and Offering characteristics, Asset Type attributes, Lens extensions, and customer extensions. OSM does not define a second language. JSON Schema is an export, not the authoring language.

Reserved prefixes, pinned lists, and units are stated below. A timestamp is RFC 3339 with an offset. A calendar date is YYYY-MM-DD. A quantity is { value, unit } with a UCUM unit. Money is { amount, currency } with an ISO 4217 code. A person is accountable_person.

Shape

A declaration has a namespaced name, a required description, an optional definition_uri (a plain URL), a value_type, requirement_tier, required, cardinality, mutability, and status (active or deprecated).

Value types: string, integer, number, boolean, date, datetime, duration, uri, version, quantity, money, reference. enum and list remain aliases. A reference names its target kind. Changing a value type requires a new name.

Vocabulary binding is exclusive. The declaration sets vocabulary_id to the id of a pinned list, or it lists allowed_values. Not both. patch_state is a vocabulary id whose tokens are not closed.

requirement_tier pairs with required:

Tier	required	Missing value
mandatory	true	Error on a new write. Warning on existing data.
recommended	false	Warning. Does not block save.
optional	false	Silent.

A declaration holds no value field. On a Service or Offering the stored value is the fixed sibling key configured_value. The declaration name is not the YAML property key. An Asset Type declaration carries no value. The Asset stores the value inside attributes[].

A quantity’s stored shape is { value, unit }. That inner value is the quantity convention. It is not a declaration field. A quantity declaration sets a fixed unit or a unit_dimension with an allowed_units subset. Ingest keeps the observed number and unit. Views convert. Stored values are not rewritten to another unit. Percentages use unit % on a 0–100 scale. Authored durations that are targets stay duration (hours, minutes, and seconds when the duration is compared with a measurement). Measured lengths of time are quantities.

Constraints are min, max, pattern, min_length, max_length, and max_fractional_digits. No silent coercion. Object type and conditional constraints are not in this set.

Names

A declaration name matches ^[a-z][a-z0-9_]*\.[a-z][a-z0-9_.]*$.

Reserved prefixes for built-ins: core, security, roi, agents, ops, capacity, compliance, hosting, identity, software. Customer declarations start with custom. or <organization_id>..

Customer extensions and Offering permitted values may only narrow: subset allowed_values or the vocabulary, raise min or min_length, lower max, max_length, or max_fractional_digits, or tighten required from false to true. They must not widen, and they must not change value_type or unit dimension.

No characteristic name is mandatory on every Service. ops.availability_target is a valid example of a recommended quantity characteristic. It is not a required field of the Service.

Person shape

Where a Technology record names a person, the field is accountable_person: required name, surname, and email; optional role. Free-text owner, accountable, and ownerPerson are rejected on new Configuration writes. Email is a correlation key, not a person-registry foreign key. There is no Person registry and no Team entity in this model.

---

Groups on Technology

Groups classify Technology records the same way they classify Organization and Business. A Group may hold direct values, container subgroups (each holding values), or both. Picks live on the Technology record as group_values, not in assignments. A direct value is addressed by groupId and valueId. A value under a subgroup also names subgroupId.

Technology validation: a Group is checked whenever it applies. A missing required pick is an error on a new write and a warning on existing data. A missing optional pick is a warning. A value inherited from a parent does not satisfy required.

Group rules may target Technology Stack, Service, Offering, and Platform. They do not target ICT Provider.

---

Rules

Catalog id segments are snake_case: a lowercase letter, then lowercase letters, digits, or underscores (^[a-z][a-z0-9_]*$). The same slug rule is used for Groups. New external fields and new closed-list values are snake_case. Tokens taken from an external standard stay verbatim. Existing published camelCase names, including Platform serviceIds and offeringIds, stay until a versioned migration.

Record	Id
Stack	One snake_case id. Optional parent_stack.
Service	Two segments.
Offering	Three segments. The first two equal the Service id.
Asset Type	Service id, a dot, one snake_case segment.
Asset	a- plus 16 lowercase alphanumeric characters.
Provider type	The six-value list under ICT Provider.
Offering adoption_status	approved, tolerated, prohibited.
Service and Offering lifecycle_state	draft, pilot, production, sunset, retired.

YAML, backup restore, and the Configuration page use one Technology validator: required fields, snake_case, and the same semantic checks used for Groups and Organization (unique ids, known references, acyclic Stack parents).

On the Configuration tree, Offerings and Asset Types are two sibling branches under each Service. Assets stay in Inventory and are not rows in that tree.

Configuration entities do not store created_at / updated_at. Authorship is the Configuration change log and backup. When a definition carries validity, valid_from / valid_to are inclusive calendar dates. A missing end is open-ended.

---

Q&A

Q1. Is a CRM or an ERP a Service?

No. If the enterprise operates it and business users work in it, it is a Platform. The business processes built on it are Business Applications. The identity test above is the order of the check.

Q2. Where do Offerings and Asset Types sit?

Both are lists on the Service: offerings and asset_types. An Asset Type belongs to that one Service. It is not nested under an Offering.

Q3. What does an Asset store to say what it is?

asset_type_id and offering_id, both of that Service, plus an opaque asset_id. Stack, Service, and Provider are derived.

Q4. Where does a characteristic’s number go?

The declaration describes the attribute and holds no number. On a Service or Offering the number is configured_value. On an Asset the number is inside attributes[]. An Asset Type declaration carries no value.

Q5. Does a missing recommended characteristic block save?

No. recommended warns. mandatory errors on a new write and warns on existing data. optional is silent. Offering lifecycle, adoption, characteristics, and provenance warn when missing and do not block save.

Q6. When can an Offering name no Provider?

When its id ends in self_hosted or custom_built. Otherwise a new Offering needs at least one providers entry. Those suffixes are the rule for a vendorless Offering. They are not a rename recipe for existing catalog rows.

Q7. Does a Provider have an Owner?

No. type is required on a new Provider. substitutability is high, medium, low, or none.

Q8. Is a Platform an Application?

No. Applications consume the Services the Platform offers. An Application and a Platform have no link; Assets show the relation when a Platform produced them. Offerings stay under the Services.

Q9. Are MTTR and execution counts stored on the Asset?

No. They are views over fact records. A metric observation is stored only when the number cannot be computed from those facts.

Q10. What is a software component?

One occurrence of a package, library, or runtime in one place. The Asset Type is the language-runtime software component. The Offering is the runtime it runs on. A second repository is a second Asset, even at the same version.

---

Examples

The following YAML illustrates the record shape. The characteristic name, the quantity, and the people are examples. They are not required content for every Service. Ten Asset Type templates are modelled and populated, and four more are structure only, one Service each, with snake_case segments. automation is two templates. data_store is two templates. Declarations use vocabulary_id and requirement_tier. An Asset Type declaration carries no value.

Service, Offering, and Asset Type

services:
  - id: compute.virtual_machines
    name: Virtual machines
    description: Virtual machines supplied as a capability, independent of which provider hosts them.
    technology_stack: compute
    lifecycle_state: production
    characteristics:
      - name: ops.availability_target
        description: Availability the enterprise expects from this capability, on a 0-100 percent scale.
        value_type: quantity
        unit: '%'
        requirement_tier: recommended
        required: false
        # Example value. This name is not required on every Service.
        configured_value:
          value: 99.9
          unit: '%'
    offerings:
      - id: compute.virtual_machines.aws_ec2
        name: Amazon EC2
        description: Virtual machines on Amazon Web Services.
        providers: [aws]
        lifecycle_state: production
        adoption_status: approved
    asset_types:
      - id: compute.virtual_machines.compute_instance
        name: Compute instance
        description: One virtual-machine instance.
        template_id: compute_instance
        declarations:
          - name: hosting.architecture
            description: CPU architecture of this instance.
            value_type: string
            vocabulary_id: cpu_architecture
            requirement_tier: mandatory
            required: true

The Asset Type declaration carries no value. A Service characteristic that repeats ops.availability_target on an Offering must keep the same value type and unit dimension, and may only narrow the constraint. Both store the number in configured_value.

Asset

asset_id: a-7f3c1ab9e0d24681
asset_type_id: compute.virtual_machines.compute_instance
offering_id: compute.virtual_machines/compute.virtual_machines.aws_ec2
belonging:
  kind: platform
  platform_id: developer_cloud_platform
attributes:
  - name: hosting.architecture
    value: arm64
    declaration_version: 1
    origin: observed
    last_confirmed: '2026-10-30T12:00:00Z'

Stack compute, Service compute.virtual_machines, and Provider aws are derived. They are not fields on this Asset.

Invalid shapes

# Offering list under the rejected key
service_offerings: []

# Value stored inside the declaration
- name: ops.availability_target
  value: 99.9

# Asset Type on two Services
# compute.virtual_machines.compute_instance
# compute.kubernetes.compute_instance   # same type id is not reused

# Recognition keys that are not in the model
category: compute
technologyRef: compute.virtual_machines

---

Non-goals

This companion does not:

• Treat starter-pack fill-ins as rules. A pack may show a particular availability number, a shared Domain, or an Offering id that ends in custom_built. Those are that pack’s data.
• Make ops.availability_target, or any other characteristic name, required on every Service or Offering.
• Treat an Application, an ERP module, or a library as a Service.
• Store Stack, Service, Provider, category, profile, or technologyRef on the Asset.
• Store MTTR, time to market, saved cost, execution counts, or the exposure view.
• Put price or contract terms on an Offering.
• Give an ICT Provider an Owner.
• Add Asset-to-Asset verbs beyond depends_on, contains, and uses.
• Put a characteristic language, or the verbs requires, hosted_on, connects_to, and backs_up_to, into the onboarding catalog.