System

This standard governs the system health position of the Platform: backups, tenant live state, connection health, and the administrative access record. Everything else in this section configures the business; this standard states whether the machinery underneath it is healthy. Most days it is glanced at for ten seconds. The days it is needed, it is needed badly: usually at the worst possible moment: so every System Administrator learns what each measure means before a warning appears. The System Administrator owns system health, backups, and restore testing; tenant live state is changed only by an owner or the System Administrator, for a recorded reason. A system setting never overrides a governing legal document, and no health measure in this standard changes an obligation stated anywhere in this library.

Backups: the measure to be certain about

Every backup is recorded: its type, scope, start and finish times, size, storage location, row and table counts, and: on failure: the error message. Completed, running, and failed backups all appear in the record.

1. The failed record is the most important one in the list. A backup system that never reports failure is a backup system that cannot be trusted; a reported failure is the system doing its job.
2. On a failure, the System Administrator reads the error message first: it is usually specific: storage unreachable, a timeout on a large table: corrects the cause, and then runs a fresh backup. A backup is never simply re-run in hope; hope is not a backup strategy.

Backups are a paid addition, enabled per tenant. A tenant without the addition sees the offer state, and backup runs are refused by the system regardless of what the screen shows: there is no way around the entitlement and no accidental way into it. An entitled tenant receives nightly backups and a Run Backup Now control, with download links that expire after 1 hour. The hour is short on purpose: the link admits its holder to the entire database. Where a longer window is needed, a fresh backup is run rather than a link extended.

Two disciplines govern backups

1. Know the recovery window. The oldest available backup is the furthest back a restore can reach. Where that point is newer than the problem being corrected, there is no restore path. That is discovered during a calm quarterly review, not during an incident.
2. Test a restore once a quarter. A restore that has been tested is a restore that works; one that has not is a hypothesis.

Tenant live state

The live indicator reads the tenant record's active marker and state, under Organization. Active means the storefront, booking, portals, and event notices run normally. Legitimate reasons to be offline are staging a new franchise before opening day, maintenance, and an account issue.

1. Taking a tenant offline is deliberate, and bringing it back is equally deliberate; both are recorded with a reason.
2. Where the indicator ever shows a state nobody set, the System Administrator checks who changed it and when in the administrative change record before changing it back. An unexpected state change is information; overwriting it without understanding destroys the information.

Connection health

Connection health is kept as one record per dependency: the payment processor, email, messaging, the database, the website, and the customer portal: with its state, the last check, the last success, the most recent error, the check duration, and a count of consecutive failures. As health checks report in, this becomes the first place to look when something is wrong and nobody yet knows what.

It is read as a summary, not a log

1. One failed check with quick recovery is noise.
2. A rising consecutive-failure count is signal, and the error text usually names the cause.
3. Check durations creeping up over days are the early warning: still working, degrading, and the time to act before it becomes an outage.

Where a summary position is presented from these records, it reflects the worst component state, not the average. An honest warning is worth more than a reassuring summary that conceals a degraded email service; "all operational" over a failing dependency is a falsehood that costs trust the first time anyone notices.

Administrative access record

Administrative access events are recorded: the person, the tenant touched, the reason, the time, the network address, and any revocation. The System Administrator reviews the record monthly: not line by line, but for anomalies: unfamiliar network addresses, vague reasons, access at hours when the person does not work. The reason field is the whole point: every access carries one. An unread access record is decoration; a reviewed one is how a problem is caught before it becomes a story. Access itself is granted and reviewed under Admin Users.

The failure patterns worth memorizing

These are not tied to one measure; they are how failures present

1. Everything breaks at once: the storefront will not load data, bookings will not save, the administrative screens spin. That is the database or the Platform core, not any single connection. A single connection failing produces local symptoms; the foundation failing produces global ones. Check the core first.
2. "The site is down" but the site loads: usually the sign-in path. Sign-in failing while everything else is healthy has a distinctive reach: nobody can get in and everything else works. It is never corrected by editing user records. A sign-in outage is corrected in sign-in configuration, not in account data; touching user records during one converts a temporary outage into a data problem that outlives it.
3. Money failing: the highest-urgency failure there is, because every minute is revenue lost. The first question is whether the fault is the Company's or the processor's: the processor's published state is checked before anything is touched. Platform-wide processor incidents happen, and correcting the Company's configuration during one adds a second problem. Where the processor is healthy, the usual suspects are expired keys, incomplete onboarding: charges enabled but payouts not: and event endpoints that have stopped responding. The Platform's processor health measure states that the connection is alive; the processor's console states what the money is doing. Both are needed. See Payments (Accounting Payments) and Settings.
4. Silence: an order placed with no confirmation; an appointment booked with no reminder. Notifications fail after the triggering action succeeds, so nobody reports an email they were not expecting. The fault surfaces from downstream effects weeks later unless someone is watching. The operator checks the email and messaging connection health, then the recipient data: blank or malformed addresses fail in the data, not the system: then the consent state: messaging to a number that has opted out fails by design, and that is the compliance position protecting the Company, never to be overridden, under Troubleshooting (Organization Settings Troubleshooting). For franchise locations, the sender identity is checked: mail from an unauthenticated domain is filtered as spam: delivered from the Platform's perspective, invisible from the customer's.
5. Slow, not down: a homepage that took 800 milliseconds last month and 3 seconds today is reporting something even though it is technically up. Duration trends are watched, not only up and down states. Where the website degrades while everything else is healthy, the most recent change is the prime suspect, and it is checked before anything else.

Controls

• Who may change system state. Backups and restores: the System Administrator. Tenant live state: an owner or the System Administrator, with a reason recorded. Connection and credential configuration: the System Administrator jointly with the Accounting Manager where money is involved, under Settings.
• Backup download links expire after 1 hour and are never extended, forwarded, or recorded in a document; a backup file is Company data of the highest sensitivity and is stored only in the backup location the system records.
• A restore is performed only by the System Administrator, only to correct a recorded problem, and its result is verified against the books under Accounting before the tenant returns to live state.
• No system setting, health measure, or restore decision overrides a governing legal document or an accounting control in Accounting, including the rule that a closed period is corrected only by reversing entry.

Records created and where they are kept

Backup records and the backups themselves, tenant live-state changes with their reasons, connection health records, administrative access records, and quarterly restore-test results are kept in the Platform's system and administrative records and retained under the Regulatory Record Retention Policy.

Escalation

A failed backup that cannot be corrected the same day, an unexplained tenant state change, a rising failure count on a money connection, or any suspected unauthorized administrative access goes to an owner the same day; suspected compromise and legal process go to legal@aapawz.com. Operational support for system faults goes to support@aapawz.com.

Review cadence

Connection health is glanced at daily and read in full weekly. The administrative access record is reviewed monthly. Backups, the recovery window, and a restore test are reviewed quarterly. This standard is reviewed after every incident it is used in.