> ## Documentation Index
> Fetch the complete documentation index at: https://archie.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# System Requirements

> Non-functional requirements your app needs to meet — regional, compliance, security, performance, and accessibility.

System Requirements covers the non-functional requirements your app has to satisfy. Five categories sit alongside each other on tabs; each one informs different parts of the generated code, the infrastructure choice, and the deployment surface.

## Regional

Where your app runs and the regions you serve. Configure target regions, data residency preferences, and any region-specific constraints. Drives the [Archie Core](/docs/features/backend/overview) region selection and influences which compliance frameworks apply.

## Compliance

Compliance frameworks that apply to your app — SOC 2, HIPAA, GDPR, and others. Archie tracks which framework you've selected and surfaces the controls that flow from it. Compliance add-ons are an Enterprise plan feature; see [Enterprise overview](/docs/introduction/enterprise/overview).

## Security

Security controls beyond defaults. The platform ships with secure defaults (AES-256-GCM encryption at rest, configurable CORS, API rate limiting, RBAC), but you can pin extra requirements here — required MFA, password complexity policies, session lifetime, audit log retention.

## Performance

Performance targets. Expected concurrent users, response-time targets, peak-load assumptions. Archie uses these to inform the recommended Archie Core backend tier and compute size — see [Plans and credits](/docs/introduction/getting-started/plans-and-credits) for the tier breakdown.

## Accessibility

Accessibility standards your app needs to meet — WCAG 2.1 AA is the typical target. Setting a target here informs the visual design defaults (color contrast, keyboard navigation, ARIA labels) and the generated component library configuration.

## How requirements flow downstream

System requirements rarely change the structure of your app, but they shape:

* **Backend tier and region** in [Archie Core](/docs/features/backend/overview)
* **Default security posture** of the generated code (encryption, sessions, headers)
* **Component library defaults** for accessibility-aware patterns
* **Compliance flags** that surface controls in audit logs and admin UIs

Most of these defaults are sensible for typical apps. Override them when you have explicit obligations.

## FAQ

<AccordionGroup>
  <Accordion title="Do I need to set every category?">
    No. Sensible defaults cover most apps. Only set explicit values when you have a specific obligation — a compliance framework you're subject to, a region you must run in, an accessibility standard your customers require.
  </Accordion>

  <Accordion title="How does setting GDPR or HIPAA actually affect my app?">
    GDPR and HIPAA are part of the Enterprise compliance add-ons. Selecting them here surfaces the relevant controls; the formal certification and Business Associate Agreement come with the Enterprise engagement. See [Enterprise overview](/docs/introduction/enterprise/overview).
  </Accordion>

  <Accordion title="What happens if my performance targets exceed what my plan supports?">
    Archie surfaces a recommendation to upgrade your Archie Core backend tier (Starter → Professional → Enterprise) so the compute matches your target. You can ignore the recommendation, but expect performance to track your tier, not your stated target.
  </Accordion>

  <Accordion title="Do these requirements affect generated tests?">
    Some do. Setting an accessibility standard prompts Archie to add accessibility-aware tests; setting compliance flags adds checks for required logging and consent flows. The depth varies by category.
  </Accordion>
</AccordionGroup>