Keep The
Lights OnA DEVELOPMENT PATTERN

Documentation · specification 0.1.0

Learn the pattern

Build AI features with a human way to finish the work. Start with the open-source skills, then follow three practical examples.

Free and open source

Bring KLOD into your project.

Give your coding assistant instructions to help you build and review software people can operate when AI stops.

Works with Spec Kit and OpenSpec.

Use KLOD in your existing workflow. Both integrations are maintained by KLOD.

Spec Kit extension

Add KLOD planning and review commands to your Spec Kit workflow.

Set up the extension

OpenSpec custom schema

Include human operation, implementation tasks and verification in your changes.

Set up the schema

Or install the two skills with APM.

With APM, the Agent Package Manager, installed, run this in your project folder:

apm install AlexandruGirlea/keepthelightson#v0.2.0
APM setup and usage

Then ask your assistant: Use klod-check to review this project.

What the two skills do
klodBuild the feature
Ask your assistant to add the AI feature, the manual path and an off switch people can use.
klod-checkCheck your project
Review AI dependencies and missing controls. Get a report with evidence gaps and next actions.
On this page

Build the human way of doing the work alongside the AI feature. KLOD asks you to keep the data, controls and knowledge people need to take over as part of the product. The free, open-source skills help your coding assistant apply this approach while you build or review a project.

Pick one job your customers or colleagues need done, such as answering a support request. KLOD calls that job a capability. The manual path is how people finish it without the AI supplier.

The six principles

The examples below show how the six principles work in practice. Each follows four steps: what to keep, what happens when AI stops, how people finish the work, and how to check the result.

Read the specification for the evidence required to declare a KLOD level (L0 to L3).

EXAMPLE 1 Answer customers when AI drafting stops

Starting design: A hosted model writes replies. An outage leaves tickets stuck waiting for a draft, even though support staff could answer them.

  1. Keep the request. Save tickets before requesting drafts. Show conversation history, policies and reply status to staff.
  2. Handle the interruption. Show that AI drafting is unavailable while keeping tickets accessible. Once AI is switched off, late drafts must not overwrite what staff have written.
  3. Let staff finish. Staff use the same queue to prioritise, write and send replies. Track pending and sent messages to prevent duplicates during recovery.
  4. Verify the result. Agree what counts as a correct reply. In an authorised real-work drill with AI unavailable, measure time from the takeover decision to the first correct reply, how much of the normal workload staff can handle, and for how long. Use those results to set customer expectations.

For invoices, keep originals, approval rules and payment status available so people can review and approve work without AI extraction.

EXAMPLE 2 Keep control of connected equipment

Starting design: Hosted AI proposes ventilation settings, and a server sends commands to building controllers. A supplier outage could cut off the service. A working model could still propose unsafe settings.

  1. Define the response first. Equipment specialists decide how people can safely operate the equipment, or which safe state it must enter. They name qualified operators and set the required response time.
  2. Block further AI commands. Give an authorised person an AI off switch. Enforce it where the controllers accept commands so queued or late AI commands cannot take effect after switch-off. Preserve safety interlocks and essential non-AI controls.
  3. Make the handover visible. Show the equipment's state and flag any commands whose outcome is unknown. Use the approved human controls or safe state. Require authorisation before AI resumes.
  4. Check safely. Test lost connections, pending commands and restarts in isolation. Plan real-equipment exercises through the established safety process. Simulation alone does not count as a real-work drill or prove how much work people can sustain.

Stopping AI from sending commands need not mean cutting power. The human-control guide explains the distinction.

EXAMPLE 3 An optional AI feature in a client app

Starting design: A report editor already lets people write, save and export documents. An optional hosted feature suggests clearer wording.

  1. Name the work. Assess completing and exporting a report. Confirm people can finish it through the normal workflow without AI output.
  2. Limit the failure to the AI feature. If rewriting fails, preserve the original text and show that suggestions are unavailable. Keep editing, saving and export working.
  3. Keep the author in control. Apply suggestions only when the author accepts them. Ignore results from cancelled requests so they cannot overwrite later edits.
  4. Test the separation. Test those actions with AI unavailable and with a request still waiting for an answer. If report completion normally works without the supplier, that capability gets no KLOD level. If automatic rewriting is itself a promised service, assess that capability separately.

Apply it to your own work

  1. Choose the work and owner. Name one capability and the person responsible for keeping it running.
  2. Write down the manual path. List the data, tools, permissions and instructions people need. Decide what gets priority and what can wait.
  3. Check the gaps. Use the self-check, then assign an owner and date to each improvement.
  4. Build and practise. Use the implementation guide to add the missing controls. Arrange an authorised drill and record Time to Manual (how long until the first correct result without AI) and manual capacity before declaring L2 or L3.

For help building or reviewing the design, use the optional KLOD skills with a coding assistant.

Next steps

Install the skills Run the self-check