Systems that maintain themselves: measure, correct, update, approve

Most software projects end with a handover. From then on the system ages: dependencies acquire security flaws, measurements drift, and faults only surface when a customer reports them.

Self-maintenance does not mean a system works on itself unsupervised. It means the work of maintenance is prepared before a person has to start it, and the decision stays with you.

Health checks, telemetry and evaluation show at all times whether the system does what it should. Latency, errors and cost are measured, and for an assistant the quality of its answers too: are they backed by sources, and does it decline where it should? An open standard such as OpenTelemetry keeps the measurements independent of any single tool.

When a measurement drifts or a scan reports a security finding, a controlled correction starts. It passes the same tests and security checks as any other change. If anything fails, the system returns to its last good state.

That requires tests that really check. A test suite can be entirely green while single tests check nothing. Mutation testing breaks the code on purpose and shows whether the responsible test goes red.

Dependencies and containers are checked continuously. The basis is a software bill of materials (SBOM), for example in the CycloneDX format, which records which components are included in which version. Newly known vulnerabilities are matched against it; container and secret scanning complete the picture.

When a flaw becomes known, the update is prepared and tested automatically. Whether it is applied is your decision.

Every change waits for your approval with traceable evidence: what changes, which checks passed and how the change is rolled back. Prepared automatically, approved by you.

The approval is not a formality. It keeps responsibility where it belongs and makes every change traceable afterwards.

This approach is in line with recognised guidance for secure software development, such as NIST's Secure Software Development Framework (SP 800-218), and with the expectation that vulnerabilities are handled over the whole lifecycle of a product. For products with digital elements, the EU Cyber Resilience Act (Regulation (EU) 2024/2847) will make this an explicit requirement.