OSYRA — Frequently Asked Questions

This FAQ explains, in plain language, what OSYRA is and how its core pieces fit together. It is conceptual (Diátaxis explanation): for step-by-step setup see the OME Python guide; for exact error codes see the Error-Code Catalog. Where a number or a compliance claim would drift over time, this page stays qualitative and points you at the canonical source rather than restating a figure that may go stale.

What is OSYRA?

OSYRA is an AI control plane — a governance, identity, and verification layer that sits between your applications and the AI providers they call. Rather than wiring each service directly to a model vendor, you route through OSYRA and gain a single place to authenticate callers, enforce policy, and track usage and cost. Verifiable records are a separately gated capability; the current customer SDK posture is offline verification, not a live write/read claim.

OSYRA is composed of several cooperating pieces. The ones a customer most often interacts with are:

• edge — the public gateway behind two trust origins: auth.osyra.ai for OAuth/discovery and api.osyra.ai for protected product APIs. Edge authenticates the caller, applies rate limits, evaluates policy scope, writes an audit record, and forwards the request internally over gRPC.
• iam — identity and access management: organizations, workspaces, users, roles, and OAuth clients.
• llm / model broker — the vendor-neutral routing layer that forwards inference calls to the configured AI provider.
• ome (OSYRA Memory Engine) — the service-side verified-memory substrate. The current customer SDK pre-release exposes offline evidence verification from an authorized checkout; its supported Edge write/read route is still pending.
• verifier — the local or service component that checks supplied signed evidence against an independently trusted key.
• policy — policy-as-code enforcement applied to requests before and after invocation.
• billing — subscription, usage, and quota tracking, with payments via Stripe.

You do not have to adopt all of these at once. A truthful current starting point is a single workspace plus gateway inference; authorized OME pre-release users can separately verify trusted committed evidence offline.

What does "vendor neutral" mean in practice?

OSYRA is designed so you are not locked to a single AI vendor. The model broker exposes a consistent surface and routes to the enabled provider mapped to an operator-assigned model ID. Moving a workload can be configuration-only when both provider adapters and the required request/response semantics are already implemented, validated, credentialed, and enabled. An unsupported transport, normalizer, or model capability requires adapter implementation and tests.

Provider-specific failures are normalized into OSYRA's own error namespace (OSY-PROV-*), so your application handles one consistent error shape regardless of which upstream provider returned the failure. See the Error-Code Catalog for the current set.

Comparative cost or savings figures are intentionally not stated here, because they depend on your workload and on features that may be forward-looking. For any cost, savings, or competitive comparison, use the current /osyra-legal-cleared materials rather than a number from this page.

Which AI providers and models are supported?

The broker codebase contains adapters for four provider families:

• OpenAI
• Anthropic
• AWS Bedrock
• Azure OpenAI

All four adapters are disabled by default. A deployment operator must enable an adapter, supply its real credentials, and register models before it can serve traffic. This list describes code-wired adapters, not market coverage, customer demand, or proof that all four are live in a given deployment. Use the authenticated deployment catalog and a successful authorized operation to establish which operator-assigned model IDs are usable.

How does authentication work?

For model access and native HTTP APIs, an IAM-issued Osyra API key is the simplest service credential. Send it in the canonical X-Api-Key header:

curl https://api.osyra.ai/v1/models \
  -H "X-Api-Key: $OSYRA_API_KEY"

OAuth 2.0 is also available when you need a short-lived access JWT, delegated user authorization, or a credential that works with transports that require a bearer token. Service-to-service callers can exchange a client ID and client secret at the authentication host:

curl -X POST https://auth.osyra.ai/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=$OSYRA_CLIENT_ID" \
  -d "client_secret=$OSYRA_CLIENT_SECRET"

A few things worth knowing:

• Use exactly one credential channel on protected routes. Native API and protected GraphQL HTTP requests accept an API key in X-Api-Key or an OAuth access JWT in Authorization: Bearer, never both. The only anonymous GraphQL operations are body-verified POST /graphql documents containing solely publicPlans or solely resendVerificationEmail.
• OpenAI-compatible Bearer is a narrow exception. Upstream OpenAI clients always emit their credential as Bearer, so an exact osy_(sandbox|test|live)_<43 base64url characters> key is accepted that way only on GET /v1/models and POST /v1/chat/completions, POST /v1/chat/completions/stream, and POST /v1/embeddings. It is not accepted as Bearer on /graphql or other native routes.
• Access tokens are JWTs signed with ES256 (ECDSA P-256). Edge obtains public keys from IAM over private gRPC, caches them for 5 minutes by default, refreshes at 80% of that TTL, and performs a bounded refetch for an unknown kid. Signature validation remains local and fail-closed.
• Client secrets are shown once, at creation time, and stored only as a hash. If you lose a secret you rotate the client rather than recovering the old value.
• Tenant/workspace scope is derived from the authenticated credential, not from the request body. The edge strips and overwrites caller-supplied OS-* scoping headers with authority from the API-key session or OAuth JWT. The optional X-Osyra-Workspace header is an equality assertion only: it may be omitted or equal the authenticated workspace. A different value returns HTTP 403; it cannot switch tenants.

API-key creation and verification are deliberately deployment-gated. IAM must have API-key crypto enabled and a KMS HMAC key configured; a deployment without that backend fails closed rather than pretending API keys are active.

The current OME customer capability is offline verification, which uses no network credential: the verifier needs exact evidence bytes, a detached signature, and an independently trusted public key. OME SDK RPC methods are pre-release protocol implementations; their supported customer Edge bridge and real acceptance lane are pending. Do not point a customer SDK directly at AP00011, and do not rely on the TypeScript constructor's reserved signing-key input as authentication.

How do billing and quotas work?

OSYRA uses a developer-first, product-led model with three plan tiers:

• FREE — for individual developers evaluating the platform. One workspace, a small number of users, a monthly API-request allowance, and a single AI provider.
• PRO — a flat monthly subscription for small teams. More workspaces and users, a larger request allowance, access to all supported providers, and basic policy limits.
• ENTERPRISE — custom-contracted for mid-market and large organizations. Unlimited workspaces/users, the full policy engine, SSO/SCIM, configurable retention, and compliance support.

The specific per-tier limits (workspace counts, user counts, request allowances, retention windows, and OME export limits) are defined in the pricing source and may be adjusted, so consult the pricing page for current values rather than memorizing a number.

How quotas behave:

• Usage is tracked continuously and quotas are enforced at the relevant entry point — for example, workspace and user limits are checked at creation time, and request allowances are enforced per request.
• When you exceed a limit, the platform returns a rejection (commonly HTTP 429 / gRPC RESOURCE_EXHAUSTED for rate/quota limits, or a 403-style upgrade-required signal when you hit a plan boundary such as creating an extra workspace). The Quickstart documents the free-tier rate behavior and how to back off.
• Payments and subscription lifecycle run through Stripe, integrated via the billing service. Upgrading (for example FREE → PRO) flows through Stripe Checkout; a successful payment webhook raises your limits, and a cancellation downgrades you back to FREE.

For the precise machine-readable error codes returned on quota or rate-limit rejection, see the Error-Code Catalog.

What is Verified Memory, and how does offline verification work?

OME defines cryptographic evidence formats for attestable memory. The capability that a customer can run from the current v1.0.0 pre-release SDKs is offline verification:

1. Obtain the exact detached Form-B signing-preimage bytes and 64-byte Ed25519 signature through a trusted evidence channel.
2. Obtain the real 32-byte signer public key independently. Do not trust a key embedded in the record; anyone can self-sign attacker-chosen bytes.
3. Verify the signature over the received preimage bytes verbatim. Do not decode and re-encode the preimage first.

A successful result proves that the exact bytes were signed by the private key corresponding to the supplied trust anchor. It does not, by itself, prove a human or service identity, retrieval completeness, data residency, or that a record came from a live Osyra deployment; those conclusions need separate trusted evidence.

There is no anonymous public package today. Authorized users run verification from a source checkout; private CodeArtifact and public registry distribution remain release-gated. Reproduce examples only with the committed KAT at AP00013-osyra-ome-sdk-python/tests/kat/verify-v1/claim-preimage-kat-v1.json and its PROVENANCE.md, or follow the fixture-based OME Python guide and OME TypeScript guide. Do not substitute invented IDs, keys, signatures, or receipts.

What error codes does OSYRA return, and where are they documented?

OSYRA uses a stable, namespaced error taxonomy — for example authentication, policy, rate-limit, provider, and memory errors each live in their own family. SDKs map these wire codes to idiomatic exceptions in each language.

To avoid drift, this FAQ does not restate specific codes or numbers. The single source of truth is the Error-Code Catalog, which lists the current codes, their meanings, the HTTP/gRPC status they map to, and recommended recovery. The Quickstart's troubleshooting section walks through the most common ones you will hit during onboarding.

Where is my data stored? (Data residency)

The engineering sources pinned by this FAQ do not establish a binding customer residency promise. This page therefore does not claim a single region, multi-region availability, EU processing, per-tenant affinity, a certification status, or a retention guarantee.

For any binding statement about data residency, GDPR handling, retention, sub-processors, or compliance posture, rely on the current /osyra-legal-cleared materials—such as your Data Processing Agreement, order form, deployment contract, and official trust documentation—rather than an inference from service topology or this FAQ.

If you have a specific residency or compliance requirement, raise it with your account team so it can be addressed against the current, legally-reviewed commitments.

Where do I go next?

• Verify real evidence offline: the OME Python guide and OME TypeScript guide use committed fixtures.
• Look up an error: the Error-Code Catalog.
• Pricing details: the pricing page.
• Anything compliance- or claim-related: ask for the current /osyra-legal-cleared materials.

OSYRA™ and OME™ are trademarks of Osyra AI Inc. © 2026 Osyra AI Inc. All rights reserved.