An AI onboarding outage can stop a new hire at the worst possible time. Required policies disappear, access instructions become unreachable, and the employee may not know who can answer a consequential question. Telling people to wait for the company brain to recover wastes the first week. Giving them an unrestricted document dump is worse because it can expose stale or sensitive material.
A controlled continuity mode keeps the essential work moving. It uses a small, permission safe fallback pack for critical tasks. The interface says when the assistant is degraded, risky questions go to named owners, and the system records work that must be replayed. Normal answers return only after recovery tests pass. This runbook shows People Operations and IT how to build that path.
Why ordinary uptime monitoring is not enough
A green application status does not prove that onboarding works. The chat interface may load while identity checks fail, retrieval times out, a model provider rejects requests, or a source system becomes unavailable. Each dependency can produce a different employee experience.
Map the complete journey rather than monitoring one endpoint:
- The employee signs in with the correct identity.
- The system loads current role, location, and employment attributes.
- Retrieval returns only permitted onboarding sources.
- The model produces an answer from those sources.
- Citation links open for that employee.
- Required actions reach the responsible system.
- Escalation reaches a named person.
The AWS Well Architected Reliability Pillar treats reliability as the ability of a workload to perform its intended function consistently and recover from failure. For onboarding, the intended function is not merely returning text. It is helping a particular employee complete a valid task with the right evidence and support route.
Define the minimum service before an incident
Decide which onboarding journeys must continue and which can wait. Do this before an outage, when owners can make careful decisions.
Classify tasks by how long they can wait. Safety instructions, security reporting, required access setup, payroll identity steps, and a route to a human owner belong in the immediate group. First week assignments, equipment requests, mandatory training, and scheduled manager actions are time sensitive. Culture reading, optional product history, broad discovery, and recommendations that do not block work can wait for recovery.
The NIST contingency planning guide covers recovery strategies, contingency plans, testing, training, and plan maintenance. Apply that discipline to the employee journey. Name an owner for each critical task, set a maximum tolerable delay, document the fallback, and test it.
Do not promise full functionality during an outage. Define a smaller service that the team can support. A narrow fallback is safer than a copy of the whole knowledge base that nobody can keep current or permission correctly.
Build a permission safe fallback pack
The fallback pack should contain only the material needed to complete critical and time sensitive work. Each item needs more than a document title.
Store these fields:
{
"task_id": "report-security-incident",
"audience": ["all-employees"],
"owner": "security-operations",
"effective_from": "2026-08-01",
"review_by": "2026-09-01",
"fallback_instructions": "Call the published security line and notify the duty manager.",
"source_revision": "security-response-v12",
"allowed_during_outage": true
}Generate the pack from governed sources on a schedule. Sign or checksum the package, encrypt it at rest, and keep access rules attached to each item. Do not export restricted executive, legal, customer, or personnel collections into a universal backup.
Every fallback item should have an effective date, review date, owner, audience, and source revision. If any field is missing or expired, the item should not become an instruction. It can instead show a contact route.
The public GitLab onboarding handbook demonstrates why explicit tasks, owners, buddies, access requests, and support paths matter. A continuity pack preserves that structure. It is not a folder of documents for a new hire to interpret alone.
Make degraded mode obvious
Do not let the interface fail silently. A slow or incomplete company brain can look authoritative while using only part of its normal evidence path.
Show a clear state such as:
> Onboarding continuity mode is active. Live company search is unavailable. The answers below come from the approved fallback pack last verified on 11 August 2026. For payroll, benefits, access, or policy exceptions, contact the named owner instead of acting on this answer.
The notice should include the incident start time, unavailable functions, age of the fallback pack, expected next update, and support route. Keep it beside each answer rather than on a status page employees may never see.
Use explicit output states. fallback_verified means an approved item applies to the employee and remains current. human_required covers consequential tasks and cases where the fallback lacks context. deferred records a task that can safely wait. unavailable means that neither a safe fallback nor an owner can be reached.
Never turn a timeout into a normal looking answer. Never ask the model to improvise from memory when retrieval is unavailable.
Protect critical work under load
An outage may be partial. The system can remain reachable while queues grow and dependencies slow down. The Google SRE guidance on handling overload explains why systems need to reject or shed work before overload causes broad failure.
Apply that idea by reserving capacity for critical onboarding journeys. During degradation:
- Stop optional summaries, recommendations, and broad exploratory searches.
- Prioritize identity setup, security, payroll, equipment, and human routing.
- Limit repeated retries from the same session.
- Return a fast explicit fallback instead of allowing long requests to pile up.
- Queue only work that is safe to replay later.
A retry storm can make recovery slower. Use capped attempts with increasing delays, then switch to continuity mode. The employee needs a reliable next step, not a spinning indicator.
Route consequential questions to people
The fallback pack cannot decide a policy exception, approve access, interpret a personal benefits case, or resolve conflicting employment data. Route these questions to the accountable team.
Create a directory that remains available outside the company brain. For each critical domain, include a team queue, duty owner, response target, backup channel, and instructions for verifying the employee's identity.
Send enough context for the owner to act:
- employee identity and approved role context;
- question and task identifier;
- fallback item shown, if any;
- unavailable dependency;
- deadline or business impact;
- actions the employee has already taken.
Do not copy an entire chat transcript by default. Minimize sensitive context and let the owner request more when necessary.
Kipwise's employee onboarding workflow combines assigned reading with searchable company knowledge. During an outage, both paths need continuity. The employee must still see critical assignments and know where to ask when search cannot provide a verified answer.
Capture deferred work without duplicating actions
Some work can wait, but it must not disappear. Record a deferred item with a stable identifier, employee, task, creation time, reason, and replay rule.
Separate read requests from action requests. A missed content search can be replayed after recovery. An equipment order, access grant, or acknowledgment may have succeeded even when the response timed out. Check the destination system before repeating an action.
Use an idempotency key for action capable workflows. The recovery worker should ask whether the operation already completed, then either reconcile the result or submit it once. This prevents duplicate accounts, equipment orders, and completion records.
Give employees a visible list of deferred tasks. They should know what the system recorded, what remains blocked, and who owns the follow up.
Recover in stages
A returning health check is not enough to end continuity mode. Restore service through controlled gates.
First, verify identity and permission data. Next, test retrieval against current source revisions. Then check model responses, citations, action integrations, and human routing. Use test identities for different roles and locations.
Run a short recovery suite:
- a permitted employee retrieves a current policy;
- a restricted employee cannot retrieve a protected source;
- each citation opens for the test identity;
- a consequential question routes to the correct owner;
- a deferred read request replays successfully;
- an already completed action is not duplicated;
- an expired fallback item stays blocked;
- the continuity notice disappears only after all required gates pass.
Keep the system in degraded mode if one critical dependency remains uncertain. Partial recovery should be described honestly.
After restoration, reconcile deferred work, notify affected employees, and review the incident. Update the pack, task priorities, ownership directory, and tests based on what actually failed.
Test the runbook with a realistic exercise
A document nobody rehearses is not a continuity plan. Run a quarterly exercise with People Operations, IT, knowledge owners, and a hiring manager.
Simulate loss of the retrieval service during a new hire's first morning. Ask the test employee to find security reporting instructions, complete an access task, locate a payroll contact, and defer a noncritical reading assignment. Confirm that restricted content stays hidden and every blocked task has an owner.
Measure task completion, time to fallback, incorrect instructions shown, failed handoffs, duplicate actions, and deferred items reconciled. Do not score the employee. The exercise tests the service and its owners.
Put one continuity path into production
Start with one critical journey, such as security incident reporting or first day account access. Define its maximum delay, owner, approved fallback item, degraded message, human route, deferred record, and recovery test. Disconnect one dependency in a controlled environment and prove the journey still reaches a safe outcome.
Connector repair alone does not provide onboarding continuity. The runbook must connect a permission safe fallback pack with degraded behavior, capacity for critical work, human handoff, replay control, and staged recovery.
Your next action is to choose one task that cannot wait through an outage and run it with retrieval disabled. Any step that depends on an undocumented person, stale export, or silent retry becomes continuity work before the next new hire relies on it.
References
- NIST SP 800-34 Rev. 1 supports contingency strategies, recovery plans, testing, training, and maintenance.
- AWS Well Architected Reliability Pillar supports designing workloads that perform consistently and recover from failure.
- Google SRE guidance on handling overload supports graceful degradation, capacity protection, and controlled rejection under load.
- GitLab onboarding handbook supports explicit onboarding tasks, owners, access requests, buddies, and support routes.
- Kipwise employee onboarding supports the product context of assigned reading and searchable company knowledge.
