# How ATLAS Works — From a Device Request to an Authenticated Power Session

> Architecture explainer · Controlled validation. How ATLAS connects device identity, operating rules, local power hardware, and cloud software into one recorded workflow.

## Follow a session (five steps)

1. **Request** — A supported endpoint asks to begin an energy session. Its device identity and session context reach the platform through a site gateway or API client.
2. **Verify** — Google Cloud Apigee applies configured API access and traffic policies to the call. PowerOS separately evaluates identity, device and session status, site policy, and approved limits. An accepted API call is not an approved energy session.
3. **Authorize** — PowerOS returns a bounded session decision. Failed checks end the request and are recorded. Policy is human-governed; no unsupervised AI issues authorizations. Authorization does not prove physical energy transfer.
4. **Transmit** — Within an approved validation setup, local transmission hardware and a compatible receiver form the physical power path. This remains engineering-validation scope. Cloud data services do not carry electrical power, and an external electricity source is required.
5. **Record** — Telemetry and session events return to PowerOS for metering, exception review, and exportable audit records. Measured energy evidence is kept separate from authorization and software events. A logged authorization is not proof that energy arrived.

Illustrative session — not live telemetry. Reference architecture; deployment details vary by approved validation scope. No measured watts, latency, or connected device is shown.

## Two paths

- **Physical power (solid):** existing electricity source → local transmitter → compatible receiver → device. Engineering-validation architecture; an external electricity source is required.
- **Control and telemetry (dashed):** site gateway / API client ↔ Google Cloud Apigee ↔ ATLAS PowerOS ↔ records and operator view. The site gateway also exchanges control and telemetry data with the local transmitter and receiver. Apigee and PowerOS sit inside a labelled Google Cloud reference-architecture boundary. ATLAS Cortex™ is inside PowerOS, not a peer control plane.

The architecture is explanatory and is not a complete deployed service inventory.

## Where Google Cloud fits

- **Apigee** — API access, configured policy enforcement, quotas and traffic management, and API observability. See https://docs.cloud.google.com/apigee/docs/api-platform/get-started/what-apigee
- **PowerOS services** — ATLAS identity, policy, authorization and session workflows on cloud infrastructure in the illustrated architecture.
- **Data and operations** — telemetry collection, evidence records, and authorized operator review.

Apigee governs access to APIs. PowerOS supplies ATLAS's energy-session rules.

Google Cloud and Apigee references describe architecture and infrastructure use; they do not imply endorsement, partnership, provider validation, or certification.

## One session, a network-wide operating record

Illustrative scenario: a condition sensor in a warehouse aisle requests a top-up session. The record carries device identity, approved policy, authorization decision, telemetry evidence, and outcome or exceptions. ATLAS Cortex™ supports human-supervised telemetry review and scheduling analysis inside PowerOS; high-consequence changes require authorized review. Shared software rules and records across sites are stated design intent, not evidence of production-scale operation.

## What has been demonstrated

- **Demonstrated in controlled software validation:** identity, authorization, telemetry and session logs, metering workflows, audit records.
- **Engineering development:** PowerLink X1 reference validation endpoint; PowerLink X2 design in validation — no silicon fabricated or characterized.
- **Deployment evidence:** RF performance, equipment authorization, and production field operation require their own validation.

No FCC equipment authorization is claimed, and no efficiency, range, wattage, field-scale, production rollout, or external customer or partner claim is made. See /validation and /scope-of-claims.

## Questions

- **Does Google Cloud transmit electricity?** No. Cloud services carry requests, decisions, telemetry and records; electrical power moves only along the local path.
- **What does Apigee do here?** It governs access to APIs. It does not decide whether an energy session is allowed; PowerOS supplies those rules.
- **Can any device use the network?** No. A session needs a supported endpoint with a compatible receiver, a recognized device identity, and a permitting site policy. Endpoints today are reference validation systems, not consumer products.
- **What is operating today?** Controlled validation of the software workflow, alongside engineering development of the PowerLink reference hardware. Production field operation is not represented.

Contact: info@atlaspower.ai · Technical review: /contact