Plan, configure, and operate Atlas.

Start with the boundary

Before deploying Atlas, identify the systems and people that own identity, proofing, authenticators, groups, roles, application configuration, resource policy, cryptographic material, time, telemetry, audit, backups, and authorization. Atlas orchestrates these authorities while preserving their ownership.

Deployment choice

Use the AIO container for evaluation, integration work, and bounded field demonstrations. Choose a production-shaped deployment when availability, external key custody, managed state, separation of duties, independent backups, or multi-node recovery are requirements. See deployment patterns.

First success criteria

• An operator can explain which source owns every identity field used by policy.
• An application request names the subject, client, resource, action, and desired assurance.
• A decision receipt identifies policy and evidence versions and the enforcement target.
• A negative test fails for the expected reason.
• The application can return to its prior route while preserving source authority.

Core concepts

Tenant and organization

A tenant is the primary policy and data isolation boundary. Organizations provide governed subdivisions inside that boundary. Cross-tenant sharing uses purpose- and audience-bound federation contracts while directories and case data remain isolated.

Subject, account, and persona

A subject is the governed entity that requests access. Source accounts, application accounts, credentials, and operational personas link to the subject with recorded evidence. A reviewed identity-binding process establishes whether two records belong to the same subject.

Resource and action

Authorization targets a resource and requested action; the application name supplies additional context. A user may view a record but require stronger assurance, approval, or a managed device to release, export, administer, or share it.

Authority and evidence

An authority owns a class of state. Evidence is an attributable observation or record considered by policy. Evidence includes source, subject binding, scope, observation time, validation, freshness, confidence where applicable, and retention semantics.

Assurance and trust

IAL, AAL, and FAL describe digital identity functions. TrustAI describes the strength of current evidence for a purpose. Neither is a role or entitlement. Resource policy determines how they affect the decision.

Identity onboarding

1. Register the source

Record source type, owner, endpoint, trust material, service identity, schema, paging and change behavior, connectivity, expected object counts, and which attributes the source is authorized to assert. Start read-only.

2. Map while preserving provenance

Map source identifiers and attributes into Atlas types. Normalize syntax separately from authority. For example, lowercasing an email address can be a deterministic transformation; deciding that email is an immutable identity key is an authority decision.

3. Reconcile

Classify records as create, exact match, candidate match, conflict, excluded, or invalid. Require review when the match could merge security-relevant history, authenticators, privileges, or trust evidence.

4. Activate lifecycle direction

Declare whether Atlas observes, imports, provisions, reconciles, or owns each object and attribute. Configure idempotency and conflict handling before write-back. Test disable, re-enable, rename, group removal, and source outage—not only create.

{
  "source": "workforce-directory",
  "object": "user",
  "source_key": "8c13…",
  "authority": { "status": "source", "display_name": "source" },
  "reconciliation": "reviewed_match",
  "write_direction": "observe_only"
}

Illustrative contract. Use the versioned OpenAPI surface exposed by the deployed Atlas release for exact fields and endpoints.

Application onboarding

Catalog the application before configuring a protocol. Capture business owner, technical owner, data classification, user populations, resources and actions, current identity route, lifecycle route, authentication requirements, session behavior, claims, groups and roles, privileged functions, keys, certificates, dependencies, monitoring, rollback, and recovery.

Select the integration

• OIDC authorization code with PKCE for modern browser and native clients.
• OAuth client credentials or token exchange for service access, with an explicit audience and proof requirements.
• SAML 2.0 for enterprise federation where that is the application’s dependable profile.
• SCIM for lifecycle where the target’s schema and patch semantics are qualified.
• A bounded adapter only where modernization cannot precede migration.

Validate negative paths

Test wrong issuer and audience, expired and future tokens, replay, missing required claims, invalid signature, stale metadata, removed group, disabled user, revoked device, failed step-up, key rotation, source outage, and rollback.

Decision contract

An authorization request should contain enough context to identify the caller and the requested operation while resolving security conclusions from authoritative policy inputs. The policy decision point resolves authoritative attributes and evidence.

{
  "subject": "atlas:subject:7b…",
  "session": "atlas:session:31…",
  "client": "mission-planner-web",
  "resource": "mission-plan:mp-1047",
  "action": "release",
  "context": {
    "device": "atlas:device:2a…",
    "network_zone": "partner-managed",
    "requested_assurance": "AAL3"
  }
}

Decision result

{
  "verdict": "STEP_UP",
  "reasons": ["AUTHENTICATION_ASSURANCE_BELOW_RESOURCE_FLOOR"],
  "obligations": [{ "type": "authenticate", "aal": 3 }],
  "policy": { "id": "mission-release", "version": "17" },
  "valid_until": "2026-10-08T18:25:00Z",
  "receipt": "atlas:decision:ad…"
}

Illustrative request and result. Exact public routes and schemas are release-versioned.

Verdict semantics

• ALLOW: the requested action may proceed while all obligations and validity constraints remain satisfied.
• STEP_UP: a named, satisfiable assurance or evidence obligation is required before re-evaluation.
• DENY: policy or a hard gate rejects the action. A different resource or action requires a new decision.
• INDETERMINATE: A required input or authority is unresolved, and the enforcement point preserves the indeterminate result.

Evidence model

Operational evidence must answer six questions: what was observed; who or what asserted it; which subject, resource, or session it binds to; when it was observed and expires; how it was validated; and how policy used it.

Decision receipt contents

• Tenant, organization, subject, session, client, resource, action, and audience bindings
• Authentication and federation assurance achieved
• Policy identifier, activated version, and bundle digest
• Evidence references, source authorities, freshness, and validation state
• Trust profile, applicability digest, projection, confidence and reason codes where used
• Verdict, obligations, enforcement target, validity, and revocation reference
• Trusted timestamps and receipt signature or integrity digest

Corrections

Record disputed evidence as a correction or retraction with reviewer authority, reason, scope, and time; calculate which decisions and projections are affected; then preserve the relationship between the original and corrected record.

TrustAI integration

Connect evidence providers by registering source authority, schema, subject-binding method, expected cadence, validity, and validation. Map observations to the thirteen Atlas trust dimensions only where the semantics match. Derive confidence from validated observations, semantic fit, freshness, and corroboration.

Minimum production gates

• The trust profile names required dimensions, weights, floors, vetoes, thresholds, evidence ages, and scope.
• The exact model bundle is independently evaluated, calibrated, signed, and approved for that profile and feature contract.
• The scorer authenticates as a workload and returns bundle, profile, evidence, and explanation digests.
• Validator status, drift, revocation budget, correction, and rollback paths are operational.
• Resource policy treats the projection as one input and retains final authority.

See the TrustAI construction and federation guide for the visual score walkthrough, verdict gates, and fingerprint boundary.

Migration workflow

A migration program is a sequence of evidence-backed route changes. Keep source discovery credentials separate from runtime federation credentials and use the least privilege needed for each phase.

1. Baseline: freeze or version the source snapshot; record versions, counts, checksums, connections, and known exceptions.
2. Discover: enumerate identities, groups, roles, applications, policies, certificates, keys, adapters, data stores, and administrative configuration.
3. Transform: map schemas and controls with explicit defaults and unsupported-state handling.
4. Reconcile: resolve identity matches, collisions, dangling references, nested group behavior, rule semantics, and entitlement differences.
5. Validate: compare protocol and policy outcomes, including negative cases and key rotation.
6. Shadow: evaluate Atlas alongside the incumbent while preserving the active enforcement route; investigate divergence.
7. Pilot: route a named application and cohort with monitoring and rollback.
8. Cut over: change one governed route, observe the acceptance window, and retain source evidence.
9. Decommission: remove authority only after dependent routes, recovery, records, keys, and retention obligations are resolved.

Production deployment checklist

Authority and custody

• External database, migration and backup owners named; restore evidence current
• Signing, encryption, root, recovery, and workload keys assigned to approved custody
• Trusted time sources and failure behavior validated
• Break-glass path is time-bounded, independently reviewed, and tested

Network and workload

• Private service paths, least-privilege egress, ingress policy, DNS, certificates and rotation validated
• Every service authenticates as a workload; no shared static administrative credential
• Tenant, subject, audience and purpose checks enforced at every cross-service boundary
• Rate limits, replay controls, body limits, and protocol timeouts negative-tested

State and recovery

• High-availability topology and quorum behavior match declared RTO/RPO
• Cross-region authority has fencing and conflict rules; replication and backup retain distinct recovery roles
• Policy, schema, key, model, configuration, and release rollback are separately exercised
• Independent backup custody can restore without the failed production authority

Operations and evidence

• Alerts have owners, runbooks, severity, response window, and validation tests
• Audit exits the primary runtime boundary and is protected against unauthorized mutation
• Retention and privacy minimize exported identity and case data
• Release receipt binds artifacts, configuration, tests, approvals, time, and deployed authority

Operational routines

Daily

Review critical service health, stale authorities, certificate and key expiry, federation issuer status, failed lifecycle operations, reconciliation queues, policy divergence, decision errors, TrustAI validator posture, and high-impact administrative changes.

Per release

Verify artifacts and signatures, execute schema and policy preflight, canary a bounded route, run negative probes through the real ingress, capture the release receipt, and retain the rollback target.

Periodic

Restore from independent backup, rotate keys and secrets, rehearse issuer compromise and regional isolation, review privileged access, validate incident export, reassess assurance acceptance, and retire obsolete protocol profiles.

API conventions

Atlas exposes release-versioned REST, GraphQL, and event surfaces. The deployed OpenAPI and schema documents are authoritative for routes and fields. Integrations should:

• Authenticate clients and workloads with deployment-approved credentials and explicit audiences.
• Send tenant and organization context through the documented binding and validate isolation at the gateway.
• Use idempotency keys for retryable mutations and preserve returned operation and receipt identifiers.
• Honor pagination, rate limits, retry guidance, asynchronous operation status, and version headers.
• Treat unknown fields as forward-compatible and unknown enum values as non-authoritative until supported.
• Keep access tokens, private keys, authenticator secrets, raw credentials, and unrestricted identity payloads out of logs.

Error handling

{
  "error": "EVIDENCE_INDETERMINATE",
  "message": "Required device posture is not current",
  "correlation_id": "atlas:request:91…",
  "retryable": true,
  "details": [{ "authority": "device-posture", "state": "stale" }]
}

Illustrative error envelope. Branch on documented error identifiers for the deployed release.