A successful demo leaves work unfinished

A prototype may work only on its creator's computer, with a particular folder open and a model already loaded. A service must handle users, configuration, persistent data, failures, and updates. Define who will operate it and what happens when that person is unavailable.

Containers package software with its dependencies in an isolated process environment. They are not automatically complete security boundaries or backups. Persistent application data needs an explicit storage arrangement. Docker volumes can preserve data beyond a container's lifecycle, but preservation is different from a tested backup. [source] [source]

Draw the service boundary

List the user interface, application service, model service, document store, database, retrieval index, logs, and backups. For each connection, identify what data crosses it, which identity authorizes it, and which component can write.

A local model does not make a web interface private. An authenticated interface does not necessarily mean its underlying model endpoint is protected. Check every entry point and avoid exposing a service more broadly to solve a local configuration problem.

Define operational checks

Health: Can the components respond? Readiness: Are the correct model and index loaded? Quality: Can the system still answer known questions with valid sources? Coverage: Are newly added files processed? Recovery: Can you restore the records and configuration?

A green health check can coexist with a stale index. A successful backup command can coexist with an unusable restore. Test the properties you actually depend on.

Plan a controlled update

  1. Identify the model, prompt, code, schema, and index versions in use.
  2. Preserve the last working configuration and relevant data backups.
  3. Run representative evaluation tasks on the proposed update.
  4. Test access boundaries and exports.
  5. Deploy within the intended scope, inspect results, and define a rollback route.
  6. Record the change and any known limitations.

For a small prototype, this can be a concise checklist. A shared service needs controls proportionate to its data and use. Adding an agent does not remove the operator's job.

Try it: a container was replaced

The application restarts successfully after an update, but all reviewed chronology corrections are gone. What design question was missed?

Check your understanding

Where the reviewed data lived and how it persisted across replacement. Inspect storage configuration and recovery options. Rebuilding a container is not the same as restoring user data. A proper test restores a backup into a separate controlled environment and verifies meaningful records, not just that a process starts.

Write the one-page runbook

Include startup and shutdown instructions, component locations, configuration sources, secret-management method, backup and restore procedure, health and quality checks, access administration, and escalation contact. Another person should be able to use it without relying on your chat history. The final test is operational: can an authorized colleague recover the intended service and confirm its data is intact?