> ## Documentation Index > Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt > Use this file to discover all available pages before exploring further. # Tier A decision sheet > The one file you fill in before a Tier A install, and what each decision does. The decision sheet is the one file you fill in before a Tier A install. It holds every decision that is yours to make: where Genesis runs, who may reach it, what it may spend, and how it is upgraded. The install reads only this file for those decisions; nothing else is edited by hand. The sheet is strict JSON. Every field below is required except `nodes`, `budget_alert_email`, `automatic_operation_consent`, `sign_in` and `infrastructure_reporting`, and any other field is refused. ```json theme={null} { "schema_version": "genesis-tier-a-decision-sheet-v1", "account_id": "123456789012", "region": "us-east-2", "cluster_name": "genesis-prod", "api_cidrs": ["203.0.113.10/32"], "daily_budget_usd": 200, "maintenance_window": { "day": "sunday", "start": "02:00", "timezone": "America/New_York", "duration_minutes": 120 }, "upgrade_policy": "approval-required", "profile": "", "nodes": {"instance_type": "t3.large", "count": 2}, "budget_alert_email": "cloud-ops@example.com", "automatic_operation_consent": true, "sign_in": { "domain": "your-tenant.us.auth0.com", "client_id": "<32-character Auth0 application client ID>", "audience": "https://genesis-api" } } ``` ## Fields | Field | What it decides | Accepted values | | - | - | - | | `schema_version` | The sheet format | Exactly `genesis-tier-a-decision-sheet-v1` | | `account_id` | The AWS account Genesis is installed into | 12 digits | | `region` | The AWS region | An AWS region name, e.g. `us-east-2` | | `cluster_name` | The name of the EKS cluster the install creates | 1-40 lowercase letters, digits or hyphens, starting with a letter or digit | | `api_cidrs` | Who may reach the cluster's Kubernetes API | 1 to 5 public IPv4 ranges, each /16 or narrower (e.g. your office or VPN egress `/32`) | | `daily_budget_usd` | The account's daily spend guardrail | A whole number of US dollars, 1 to 10000 | | `maintenance_window` | When disruptive upgrades may happen | `day`: a lowercase weekday; `start`: `HH:MM`, 24-hour; `timezone`: an IANA name such as `Europe/London`; `duration_minutes`: whole hours, 60 to 1440 in steps of 60 | | `upgrade_policy` | How upgrades are approved | See below | | `profile` | The installer profile Genesis approved for your target | The name Genesis gives you after you agree the target (guide, step 0) | | `sign_in` (optional) | How people sign in to Genesis | `domain`: your Auth0 tenant host; `client_id`: the 32-character client ID of a Single Page Application; `audience`: the `https://` identifier of the API. No secrets: a `client_secret` field is refused | | `infrastructure_reporting` (optional) | Whether the management agent reports your cluster's AWS health to Genesis | `true` or `false`. Default: `false` | | `automatic_operation_consent` (optional) | Whether upgrades may run on their own in your window, under your policy, from the start | `true` or `false`. Default: `false` (upgrades start paused) | | `budget_alert_email` (optional) | Who receives the daily budget's alerts | One email address. Default: Genesis's operations address | | `nodes` (optional) | The size of the cluster's node group | `instance_type`: `t3.large`, `m6i.large` or `m6i.xlarge`; `count`: 2 to 20. Default: 2 x `t3.large` | ## What each decision does * **Target and profile.** The profile is reviewed by Genesis and lists the exact account, region and cluster it approves. The install refuses a sheet whose target its profile does not approve, so a mistyped account or region cannot install somewhere unintended. * **API access.** Only the `api_cidrs` ranges can reach the cluster's Kubernetes API. Ranges wider than /16 are refused because they would open the API to a large public block. * **Daily budget.** The install creates (or checks) an AWS Budget named `genesis-tier-a-daily`. It covers **all spend in the account**, not only Genesis, so size it for the infrastructure the install creates plus anything else the account runs. The infrastructure (the EKS control plane, the NAT gateway and the nodes) costs money every hour it exists. Alerts fire at half, three quarters and all of the amount, to `budget_alert_email` (Genesis's operations address if you leave it out). A new install is refused once reported spend for the day reaches half. AWS billing data lags by hours, so treat this as a guardrail, not a hard stop. To change the amount later, delete that budget and run again; otherwise the install refuses because the existing budget differs from the sheet. The alert address is used only when the budget is created: a different address in a later sheet is not applied, so change it in AWS Budgets or delete the budget first. * **Node group.** The preflight checks that your On-Demand Standard vCPU quota has room for `count` x the instance type's vCPUs (2 for `t3.large` and `m6i.large`, 4 for `m6i.xlarge`), on top of what is already running. * **Sign-in.** With `sign_in`, the application requires people to sign in through your Auth0 tenant. Without it, the application installs with sign-in off. Create the Auth0 application as a **Single Page Application**. Its allowed callback, logout and web-origin URLs must be exactly `http://localhost:18080`, the fixed address that `open` uses (guide, step 6). The sheet carries only identifiers, never a secret. **Your whole Auth0 tenant is the boundary.** Genesis accepts anyone your tenant authenticates for this application. It also accepts an access token that your tenant's userinfo endpoint accepts. A person's Genesis account is created the first time they sign in, and **new users are administrators by default**. So, before you enable sign-in: * turn off public sign-ups in your Auth0 tenant; * enable only the connections you intend (for example, your company's Google Workspace or SSO) on this application; * have the person who should administer Genesis sign in first, then use Users & roles to move everyone else to a non-administrator role. * **Infrastructure reporting.** With `"infrastructure_reporting": true`, the management agent reads the cluster version, node-group health, instance health and add-on versions through its read-only role, and reports them to Genesis. It is off by default: without it, the agent reports nothing about the AWS infrastructure. The role exists either way (see the [permission appendix](/docs/deployments/AWS/Tier-A/Permission-Appendix)). * **Maintenance window, upgrade policy and consent.** With `"automatic_operation_consent": true`, the install starts the upgrade controls **unpaused**, with your window and policy. Consent removes only the initial pause; your policy still applies. Under `approval-required`, every upgrade still waits for your approval, and under `approve-then-next-window` an approved upgrade still waits for the window. Without consent, the controls start **paused** and nothing upgrades until they are enabled. Either way the install sets the controls only once: a retry or a reinstall never overwrites controls that already exist, including a pause you set later. The maintenance window governs when an upgrade may **start**. An upgrade that starts inside the window runs to the end, even if that is after the window closes. An upgrade takes about an hour, and a rollback after a failed upgrade adds about 20 minutes, so a window of at least two hours keeps the whole upgrade inside it. ## Upgrade policies | Policy | Meaning | | - | - | | `automatic-in-window` | Upgrades apply automatically, but only inside the maintenance window | | `approval-required` | Every upgrade waits for your explicit approval | | `approve-then-next-window` | An approved upgrade waits for the next maintenance window | | `by-version-class` | Stable forward patch and minor upgrades are automatic in the window; anything else needs approval | Pausing upgrades always wins over the policy.