# Status and Readiness

Source: https://docs.generalaugment.com/guides/status-and-readiness/
Description: Current public health, commercial, compliance, support, and Spark readiness posture.

General Augment is GA: the agent control plane for apps that need `/v1/responses`,
project-scoped API keys, governed tools, memory, usage controls, and the hosted
GCP-first runtime. It is the production path for app-developer backend integrations and
Spark-style tenant agents.

This is the public product and engineering readiness statement for third-party
developers. Customer-specific SLAs, DPAs, BAAs, invoices, retention schedules, and
regulated attestations live in signed Enterprise terms or customer diligence packets.
It is not a signed service-level agreement. DPA and BAA templates, legal terms, and
customer-specific attestations require signed customer review.

## Public surfaces

| Surface | URL or path | Current posture |
| --- | --- | --- |
| Developer docs | `https://docs.generalaugment.com` | Live public docs for app developers. |
| Dashboard | `https://app.generalaugment.com` | Live, with protected project setup surfaces. |
| API | `https://api.generalaugment.com` | Live hosted API for backend calls. |
| App readiness | `GET /health/ready` | Current hosted app-polling source of truth. |
| Operator health | `GET /health/detailed` | Operator/smoke-test provider and dependency view. |
| Public status page | `https://status.generalaugment.com` | Vercel-hosted page with a same-origin `/api/status` health summary. |
| Support | `support@generalaugment.com` | GA developer support path; formal SLAs are available through signed Enterprise terms. |

Apps should poll `GET /health/ready`
(`https://api.generalaugment.com/health/ready`) for request-serving readiness and keep
response IDs, trace IDs, and idempotency keys in app logs for support. `GET /v1/health`
is the v1-prefixed compatibility readiness path. The public status page is the
human-facing view; the status smoke checks the status page, both API health paths, docs,
and dashboard.

## Integration-ready today

- `POST /v1/responses` for backend-originated app turns with project-scoped API keys.
- Portable model tiers: `simple`, `balanced`, and `complex`.
- Stable user scoping through the `user` field.
- Response IDs, trace IDs, token usage, latency, model metadata, and cost metadata when
available.
- W3C `traceparent` and `tracestate` propagation.
- Installed CLI verification with explicit `project_key_execution` status: `PASS` when
the configured project-scoped key calls `/v1/responses`, `SKIP` when only project-key
existence was verified from broader admin auth.
- Semantic SSE event streaming.
- Memory store, search, profile, single-memory delete, and user-memory purge endpoints.
- Project API key creation, masked listing, updates, and revocation.
- Usage rollups, daily counters, plan limits, budget gates, and stable `402` / `429`
error reasons.
- Tool registry, generated OpenAPI-backed tools, MCP-backed tools, tool policy, audit
rows, and approval flows.
- Local mock testing for Responses and memory contract tests.

## Commercial readiness

General Augment records technical metering: usage events, daily usage rollups,
per-turn metadata, budget gates, usage-threshold webhooks, usage-credit reservations,
settlement, refunds, cancellation releases, and optional Stripe meter export when
configured.

The launch packaging in [Pricing](/pricing/) is the GA self-serve rate card for
implementation and controlled launch packets.
Hosted Stripe Checkout handoff for Build/Pro/Team, hosted credit top-up Checkout handoff,
hosted Stripe Customer Portal handoff, webhook-backed checkout activation,
cancellation downgrade, invoice history, payment-failure events, subscription-included
credit grants, paid-top-up credit grants, billing exports, and auto top-up preflight
history exist when Stripe is configured. Live-card collection is promoted after live
production Price IDs, Stripe secrets, checkout/webhook smoke proof, purchase-order
workflows, and billing policy checks are attached to the customer launch packet.
Automatic off-session auto top-up charges stay disabled unless the tenant explicitly
accepts them.
This is not a complete customer billing lifecycle until live Stripe artifacts, signed
terms, support process, refund handling, and customer-specific launch evidence are
attached.

The V1 self-serve package is Free, Build, Pro, Team, and Enterprise. Free, Build, Pro,
and Team plans have finite daily agent-turn, tool-call, and token gates in the backend.
Operators can adjust known limits through validated runtime
configuration, but invalid or unlimited public-plan overrides are ignored.

For production tenants, commit the billing mechanism, included usage, overages, payment
terms, support level, and any rate window in a signed agreement or explicit manual
operator process before launch.

## Security and compliance posture

The hosted launch baseline runs in Google Cloud `us-central1` and uses managed
encryption at rest. Project API keys are hashed before storage, and raw provider
credentials or OAuth tokens are kept in Secret Manager or the General Augment
credential vault.

Current enterprise options to understand before launch:

- Customer-selectable region pinning, EU-only residency, and multi-region active-active
residency are Enterprise deployment options handled through a customer launch packet.
- Tenant-owned model-provider key custody is available for governed model routing and is
the production default for cost-bearing model capacity, but every launch that uses it
needs tenant-specific provider smoke before General Augment claims the route is
launch-ready. Customer-managed encryption keys, customer-controlled key destruction,
and contractual key-custody guarantees are Enterprise deployment commitments captured
in signed terms.
- SOC 2, ISO 27001, HIPAA, DPA, BAA, audit rights, contractual incident response,
and customer-specific retention commitments are handled in customer diligence and
signed Enterprise terms.
- HIPAA mode is a technical guardrail for health-data workflows; production regulated
claims are made from the accepted customer agreement and launch packet.

See [Security](/guides/security/) for the full region, deletion, training-use,
credential, and DPA/BAA posture.

## Deletion and retention

Tenant-facing memory deletes and user-memory purges remove scoped memory rows from the
primary database after the request commits. Admin user deletion removes the selected
General Augment user row for the project and cascades database rows linked through
foreign keys. Project archive is a status change, not a hard delete.

For the current GCP launch baseline, Cloud SQL automated backups and point-in-time
recovery keep seven retained backups and seven days of transaction logs. Deleted primary
data can remain recoverable inside backups/PITR for up to that configured seven-day
window. Broader purge, backup-destruction, or regulated deletion guarantees belong in
signed retention terms.

## Spark and third-party launch guardrails

Before promising a production Spark or third-party launch, capture or explicitly accept:

- Public status page: keep `https://status.generalaugment.com` green in status smoke
before treating the page as launch evidence.
- Commercial mechanism, rate window, overages, support tier, and which tenant-owned
provider/API accounts pay model, channel, and tool costs.
- Burst capacity: current evidence supports controlled low-volume GA tenants,
including the 90 req/min controlled-tenant profile. Higher sustained burst
commitments must prove the selected provider path. For tenant-owned capacity, the
burst artifact must show tenant-provider attribution for every successful response and
attach non-secret provider quota evidence. For platform-managed capacity, General
Augment attaches successful recorded burst artifacts, autoscaling evidence, provider
quota confirmation, and Vertex quota evidence records to the launch packet. Publish
sustained capacity claims only when a matching capacity evidence artifact passes.
- Commercial/compliance package for DPA, BAA, SOC 2/ISO, residency, deletion,
retention, incident response, and training-use language when those commitments are in
scope.
- Optional provider verification for every provider included in the launch package.
- Named owner, shared blocker board, weekly partner sync, and sanitized repro process.
- App-developer onboarding proof: rerun the hosted tenant smoke after each launch
candidate deploy and keep the `genaug onboarding verify --json` artifact.
- Trace/support-bundle proof: verify returned trace IDs can be retrieved and match
response ID, app user, model, usage, caller metadata, SOUL/skill evidence, and
tool-call audit behavior. Controlled tenant launch packets require explicit skill
trace evidence from the multi-user behavior smoke, not only final-answer text.
- Memory behavior: explicit memory store/search/profile and per-user memory-context
scoping are covered. Treat autonomous `/v1/responses` memory final-answer behavior as
launch-proven only when the hosted tenant smoke reports
`autonomous_memory_recall=PASS` with explicit recall-tool or support-bundle memory
fact evidence.
- CLI/SDK compatibility: compare installed `genaug --version`, SDK package versions,
docs version copy, and API health/build metadata in the launch artifact. Controlled
tenants can use installed packages, repo-local packages, or local package artifacts
according to their deployment environment.

Useful next reads: [Developer Support](/guides/support/), [Roadmap and Intake](/guides/roadmap-and-intake/), and [API Stability](/guides/api-stability/).