# AI Reality Check Architecture Summary

Production domain: https://airealitycheck.co
Public API quickstart: https://airealitycheck.co/api-docs
OpenAPI specification: https://airealitycheck.co/openapi/ai-reality-check-v1.yaml

AI Reality Check provides continuity assurance for AI workflows. The core question is not only whether output quality changed, but whether the approved workflow, intent, constraints, source requirements, and expected action still hold together after an AI output changes.

Public market-signal and FAQ context is available at https://airealitycheck.co/market-signals.

## System Shape

- Frontend: Vite and React application with route-based pages for consumer checks, pricing, enterprise overview, architecture, auth, history, and reports.
- API surface: Vercel serverless functions consolidated through `api/v1.ts` for `/api/v1/...` enterprise routes, plus dedicated checkout, webhook, and health functions.
- Database: Supabase/Postgres with `arc_` tables for profiles, reports, credits, payment events, tenant policy, usage, audit, jobs, and enterprise administration.
- Payments: Stripe Checkout sessions are created server-side. Verified Stripe webhooks grant credits and update entitlements.
- Scoring: The SMI Morphological Continuity Engine is deterministic and rule-based. It does not call external AI APIs.

## Enterprise Authority Boundary

Protected enterprise operations enter a shared server-side authorization boundary before business logic runs. The boundary handles:

- request ID creation
- environment checks
- Supabase user authentication or API-key authentication
- tenant resolution
- user role or API-key scope validation
- tenant policy and module entitlement checks
- trial/status validation
- safe structured errors
- usage and audit recording where appropriate

Frontend state may display capabilities, usage, locked state, trial state, or module availability. It does not authorize scoring, tenant access, unlocks, credit deductions, API-key access, audit access, or report access.

## Continuity Score Input

The launch API route is `POST /api/v1/smi/score`.

The recommended continuity comparison fields are:

- `goal`: business or workflow goal
- `prompt`: prompt or instruction that produced the changed output
- `approvedBaseline`: approved or expected output
- `changedOutput`: changed or new AI output to assess
- `expectedFormat`: optional format requirement
- `targetAudience`: optional audience context
- `painPoints`: optional known constraints or concerns
- `aiOperatingMetadata`: optional caller-declared platform/workflow metadata

## Continuity Score Output

The response includes deterministic score data, reason codes, a trinary decision, recommendation, confidence, resonance signature, canonical audit hash, usage/audit status, and a `reportId` when tenant policy enables persistence.

## Storage Posture

Enterprise pilot default is summary-only storage:

- safe score summaries
- hashes
- request IDs
- audit metadata
- normalized operating metadata

Raw prompt, baseline, and output storage requires explicit tenant policy approval.

## Launch Limitations

The first pilot platform intentionally does not expose production streams, durable batch workers, FTP/SFTP/SSH ingress, or unbounded report-read APIs. Those are post-launch expansion areas after pilot evidence and operational needs are confirmed.