← Back to catalogue
Research draft

cloud computing

vr.tr.cloud-computing · PHY.OBJ

Enable an AI agent to recognise cloud computing arrangements, assess their operational and governance state, and determine which resource and service actions are justified.

Thing Registry Physical world and living systems

Research draft, second pass

A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.

recalled by Codex without web access - no source was read

Researched by: Codex

Purpose and description

Enable an AI agent to recognise cloud computing arrangements, assess their operational and governance state, and determine which resource and service actions are justified.

Cloud computing is a model for enabling on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service-provider interaction.

It can be Classify an arrangement as cloud computing, another hosting arrangement, or unresolved using recorded evidence.; Provision, resize, scale, suspend, or retire resources within verified permissions and service limits.; Select service and placement options against workload, isolation, location, and recovery requirements.; Evaluate service health and initiate authorised failover or restoration procedures.; Attribute consumption and estimate the cost consequences of scaling, replication, and data transfer.; Assess and execute authorised workload and data migration using verified export and deletion capabilities..

Distinguishing features

A consumer can obtain configurable resources through an on-demand service interface without a separate manual provider intervention for every allocation.

Resources are accessible over a network through defined service interfaces; remote access alone does not establish that an arrangement is cloud computing.

Capacity comes from a managed resource pool with allocations abstracted from particular physical machines; virtualisation alone is insufficient.

Capacity can expand and contract through supported allocation mechanisms, subject to quotas and actual availability; a fixed hosted server does not establish elasticity.

Resource use is measured at defined service boundaries, even when the charging arrangement is not pay-per-use.

Scope

+ Cloud qualification and service delivery characteristics

+ Service and deployment models and their responsibility boundaries

+ Resource placement, tenancy, connectivity, and dependencies

+ Provisioning, scaling, resilience, and service lifecycle

+ Identity, data governance, consumption accounting, and exit conditions

- Physical design and maintenance of servers, storage devices, and data centres

- Application business logic and domain-specific correctness

- General internet infrastructure and telecommunications service models

- Virtualisation and container technology considered independently of cloud service delivery

- Cloud provider corporate structure and general procurement processes

Characteristics

Service model
IaaS, PaaS, SaaS, mixed, or unresolved; record the capabilities exposed Determines which infrastructure and software layers the consumer can configure and must operate.
Deployment model
Public, private, community, hybrid, or unresolved Distinguishes access and organisational arrangements from the service model.
Provisioning latency
Seconds or minutes from accepted request to usable resource, with resource type and percentile Tests whether capacity can arrive within workload and recovery deadlines.
Elasticity envelope
Minimum and maximum capacity in service-specific units, plus scale-out and scale-in rates Makes scaling limits explicit instead of assuming unlimited capacity.
Allocation headroom
Quota minus current allocation, in vCPU, GiB, requests per second, or other defined service units Identifies quota constraints while keeping quota distinct from guaranteed physical capacity.
Tenancy isolation
Shared or dedicated at specified compute, storage, network, and control-plane boundaries; unknown where unverified Supports assessment of interference, access separation, and placement requirements.
Responsibility allocation
Provider, consumer, and third-party duties mapped to each service component Prevents security, recovery, and maintenance tasks from falling between parties.
Resource lifecycle state
Requested, provisioning, ready, degraded, suspended, deleting, deleted, or failed Constrains valid operations and distinguishes requested changes from completed changes.
Service availability
Successful eligible requests or available time as a percentage over a specified window Allows evaluation against workload objectives using an explicit measurement boundary.
Recovery objectives
Recovery time objective and recovery point objective in seconds, minutes, or hours Connects outage and data-loss tolerances to recovery design and testing.
Data location
Data classes linked to primary, replica, backup, log, and processing locations Exposes data movement that a single selected region may not describe.
Consumption and cost
Metered units and currency per billing interval, with rates, commitments, and transfer charges Supports attribution, forecasting, and comparison of feasible deployment actions.

Also called

cloud storagehybrid cloud storageOracle Cloud Storagepersonal cloudblock-level storageElastic cloud storageCloudLockerDeveloper PortalGreen cloud computingserverless computingmobile cloud computingplatform as a serviceinfrastructure as a servicerecovery as a serviceGeoAIaaScloud hostingprivate cloud computing infrastructureIntel Tiber Developer Cloudprivate cloudCombat cloudmodel as a servicecooperative storage cloudHP ePrintpublic cloudManaged private cloudCloud native computingSecure Access Service Edge

Where this came from

wikidata · CC0 1.0

Drafted structure

Bundle to layer to finding to question, as the second pass will find it: 7 bundles · 13 layers · 19 findings · 31 questions.

Cloud service identity Establishes what makes the arrangement cloud computing and identifies the service boundary being modelled.

Remote hosting, virtual machines, and cloud-branded products cannot be distinguished reliably by their names.

Cloud qualification

Examines observable resource delivery characteristics.

Essential service behaviours

Record evidence for on-demand self-service, network access, resource pooling, elasticity, and measured use.

  1. Which interfaces and observed behaviours demonstrate each cloud characteristic for this arrangement? definition
  2. Which missing or unverified characteristics leave its classification as cloud computing unresolved? boundary

Service abstraction

Separates the cloud delivery model from individual offerings and deployed resources.

Consumer control surface

Describe the capabilities supplied and the configuration authority retained by the consumer.

  1. Does the consumer control infrastructure, an application deployment environment, application settings, or a combination? boundary
  2. Which service documentation and version establish the available configuration and operating responsibilities? provenance
Resource pooling and placement Captures how pooled capacity is partitioned, located, and connected.

Cloud resource identifiers conceal physical placement and shared dependencies that affect isolation and failure exposure.

Tenancy and allocation

Identifies sharing boundaries and constraints on obtaining capacity.

Pool isolation and capacity

Distinguish logical isolation, dedicated allocation, administrative quotas, and actual capacity availability.

  1. At which compute, storage, network, and management boundaries are resources shared or dedicated? boundary
  2. What quotas, reservations, and observed allocation failures limit usable capacity in the selected location? measurement

Placement and connectivity

Maps resource locations, network paths, and dependencies relevant to workload behaviour.

Location and dependency map

Record regions, failure domains, endpoints, and cross-location service dependencies without assuming provider labels imply independence.

  1. Which regions, failure domains, network paths, and external services does the deployment depend on? boundary
  2. What measured latency, throughput, and transfer volume constrain placement or cross-location operation? measurement
Provisioning and elasticity Models resource requests, lifecycle transitions, and changes in allocated capacity.

Cloud actions are often asynchronous and constrained by quotas, warm-up time, and stateful workload behaviour.

Resource lifecycle

Tracks requested configuration, observed state, and completion evidence.

Provisioning state and reconciliation

Record how resource operations complete, fail, retry, and converge on intended configuration.

  1. What evidence establishes that a requested resource is usable rather than merely accepted by the control plane? measurement
  2. How can an agent retry or reconcile a failed operation without creating duplicate resources or orphaned charges? action

Elastic capacity control

Connects demand signals to supported scaling actions and limits.

Scaling envelope and triggers

Specify scaling dimensions, trigger signals, delays, and conditions for safely removing capacity.

  1. What capacity range and response time can scaling achieve under the relevant quotas and workload conditions? measurement
  2. Which signals permit scale-out or scale-in, and what draining or state-transfer steps must precede capacity removal? action
Service continuity and recovery Relates cloud service health and dependency failures to workload availability and recoverability.

A provider service commitment does not establish that a particular deployment survives outages or data loss.

Health and failure boundaries

Distinguishes workload health, service commitments, and shared failure exposure.

Availability evidence

Record health indicators and availability calculations at the consumer-visible service boundary.

  1. Which indicators distinguish application failure, data-plane failure, and loss of management access? measurement
  2. Which dependencies can fail together, and how does that affect claims of zone or region redundancy? boundary

Backup and failover

Examines whether recovery mechanisms meet stated workload objectives.

Tested recovery capability

Separate replication, backup, restoration, and failover, recording evidence of their outcomes.

  1. What recovery time and recoverable data point were demonstrated by the most recent relevant recovery test? measurement
  2. What permissions, dependencies, and consistency checks are required before failover or restoration can proceed? action
Cloud trust and data governance Defines administrative authority, shared duties, and controls over data across managed services.

Cloud consumers delegate operation while retaining responsibilities that vary by service and data flow.

Identity and shared responsibility

Maps actors, privileges, and security duties to the cloud service boundary.

Authority and control ownership

Identify who may operate resources and who owns patching, configuration, access review, and incident response.

  1. Which provider, consumer, and third-party actors own each relevant security and operational control? boundary
  2. Which identity, role, and approval conditions authorise an agent to change resources or access their data? action

Data location and protection

Tracks data copies, processing locations, encryption control, and retention behaviour.

Data custody across services

Account for primary data, replicas, backups, logs, and service-generated copies as distinct custody paths.

  1. Where are each data class and its derived copies stored or processed, and who controls access and encryption keys? boundary
  2. Which read contractual terms, configuration records, or audit evidence support location, retention, and deletion claims? provenance
Cloud economics and exit Connects metered consumption to cost and assesses the practical ability to leave or replace services.

Elastic consumption, transfer charges, commitments, and proprietary dependencies can change which actions are feasible.

Metering and cost attribution

Identifies chargeable dimensions and attributes them to workloads and decisions.

Usage-to-charge reconciliation

Record meter definitions, rate applicability, commitments, and costs that persist after compute stops.

  1. Which compute, storage, request, licence, and data-transfer meters contribute to the workload's cost? measurement
  2. What incremental and continuing charges would follow scaling, suspension, replication, or deletion? action

Portability and service exit

Examines export, replacement dependencies, migration effort, and termination completion.

Workload and data exit path

Assess whether data, configuration, identities, and service behaviour can be transferred or reconstructed elsewhere.

  1. Which proprietary APIs, formats, identity bindings, and managed behaviours require replacement during migration? boundary
  2. What verified export, cutover, retained-copy handling, and resource-closure steps complete an exit within time and cost limits? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.

A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.

Reported evidence

Findings from the breadth pass, kept separate from the structural claims.

Check these first

Recalled without web access and unsourced; every item is a lead to verify.

  • This describes the computing service model, not a physical object; the supplied PHY.OBJ classification warrants review.
  • The kinds list combines two independent classifications: service models and deployment models; community cloud is another recognized deployment model.
  • Standards are recalled without source inspection; editions and applicability need verification. No universal capacity, latency or availability range applies.
  1. Which of these check these first hold for the sense of cloud computing this model covers, and on what evidence? provenance

Kinds and varieties

Recalled without web access and unsourced; every item is a lead to verify.

  • Infrastructure as a service (IaaS)
  • Platform as a service (PaaS)
  • Software as a service (SaaS)
  • Public cloud
  • Private cloud
  • Hybrid cloud
  1. Which of these kinds and varieties hold for the sense of cloud computing this model covers, and on what evidence? provenance

Standards and regulation

Recalled without web access and unsourced; every item is a lead to verify.

  • NIST SP 800-145, The NIST Definition of Cloud Computing - National Institute of Standards and Technology.
  • ISO/IEC 22123-1, Cloud computing - Vocabulary - ISO and IEC.
  • ISO/IEC 27017, guidance on information security controls for cloud services - ISO and IEC.
  • ISO/IEC 27018, protection of personally identifiable information in public clouds acting as PII processors - ISO and IEC.
  1. Which of these standards and regulation hold for the sense of cloud computing this model covers, and on what evidence? provenance

Real-world use

Recalled without web access and unsourced; every item is a lead to verify.

  • Hosting applications and websites with capacity adjusted to demand.
  • Storing data and supporting backup and disaster recovery.
  • Running analytics, scientific workloads and machine-learning training.
  • Delivering business software through network-accessible services.
  • Provisioning development and testing environments.
  1. Which of these real-world use hold for the sense of cloud computing this model covers, and on what evidence? provenance

Failure modes and hazards

Recalled without web access and unsourced; every item is a lead to verify.

  • Provider, regional or network outages can make services unavailable.
  • Misconfigured access controls or compromised credentials can expose data and resources.
  • Resource contention, quotas and service limits can impair performance or prevent scaling.
  • Uncontrolled consumption and data-transfer charges can produce unexpected costs.
  • Provider-specific interfaces and data dependencies can make migration difficult.
  1. Which of these failure modes and hazards hold for the sense of cloud computing this model covers, and on what evidence? provenance

Regional variation

Recalled without web access and unsourced; every item is a lead to verify.

  • Data residency, privacy and cross-border transfer requirements vary by jurisdiction.
  • Available regions, services, network connectivity and prices differ geographically.
  1. Which of these regional variation hold for the sense of cloud computing this model covers, and on what evidence? provenance

Neighbouring kinds and how to tell them apart

Recalled without web access and unsourced; every item is a lead to verify.

  • Virtualization - Virtualization abstracts computing resources; cloud computing adds a service model with on-demand access, resource pooling, elasticity and measured usage.
  • Traditional hosting - Hosting alone need not provide on-demand self-service, rapid elasticity or pooled resources characteristic of cloud computing.
  • Distributed computing - Distributed computing concerns coordinated computation across multiple computers; it does not necessarily provide cloud service characteristics.
  • Edge computing - Edge computing places processing near data sources or users; cloud computing describes resource delivery and management, and the two can overlap.
  • Data center - A data center is a physical facility housing computing infrastructure; cloud computing is a service-delivery model that can use such facilities.
  1. Which of these neighbouring kinds and how to tell them apart hold for the sense of cloud computing this model covers, and on what evidence? provenance

What the second pass must settle

  • Does an existing Vercy world model already own cloud computing or its service-delivery abstraction, requiring this registry entry to link to it?
  • How should the registry's PHY / PHY.OBJ placement relate to cloud computing's service and operational aspects without duplicating neighbouring models?
  • Which authoritative definitions and versions should govern qualification, especially for arrangements with limited elasticity or dedicated capacity?
  • Which provider-specific evidence is sufficient to substantiate isolation, failure-domain independence, data location, and deletion?
  • How should composite, serverless, edge, and hybrid arrangements be represented when their components expose different responsibility and metering boundaries?