OpenPing Technology
AI Operations Framework
The core asset is not any single tool but an organisational design that lets AI safely take on real operational work: separated host lines, the three-stage update, separation of production from acceptance, change gates, data classification and handling boundaries.
What Most "AI Operations" Avoids Is the Hardest Part
Most of it concerns analysis and advice: letting AI read logs, find anomalies and suggest a direction. That class of application has value, but it avoids the hardest part of operations — the moment you actually have to act.
This framework is designed so that AI can genuinely perform installation, configuration, deployment, change and document production, with an auditable process, verifiable results and traceable errors.
Separated Working Host Lines
AI working hosts are separated by type of work and technology stack rather than one general-purpose host handling everything. The lines cover dispatch and scheduled checks, implementation (further divided by language and target platform), document production, document acceptance, code acceptance, report handling and triage, network administration and deployment.
There are three reasons for separating them: different work needs different toolchains, different work may read different classes of data, and concurrent work has different collision surfaces in version control.
The Three-Stage Update and Four Iron Rules
Before any work begins, a three-stage update is performed without exception: first the navigation and standards layer, then the standards documents for this particular task as listed by its guide, and only then the target of the work. The order cannot be swapped.
- Follow the documents, not your memory
- The index comes before the content
- Follow the documents and process the guide lists; do not decide the method yourself
- Write problems into the report; do not work around them yourself
The fourth rule covers four situations: the task guides do not cover this kind of work, the process is wrong or the rules contradict one another, a missing document makes the work impossible, and any opinion or improvement suggestion about the standards themselves. All four go into a report handled by a dedicated role; the AI performing the work neither edits the standards itself nor guesses a method and carries on.
Framework Elements and the Problems They Solve
| Framework element | Problem solved | How it is realised |
|---|---|---|
| Documents Are the Authority | Practice stays in a senior engineer's head; when they go, the capability goes | All standards managed as version-controlled documents, stating scope and source of authority |
| Three-stage update | Working from memory and reading superseded rules | Navigation layer → standards layer → target of the work, in an order that cannot be swapped |
| Task guides | Not knowing which standards this kind of work requires | Required-reading lists organised by type of work, including common omissions and past lessons |
| Production separated from acceptance | One reasoning habit both making an error and failing to see it | The producing party and the accepting party must be different model families |
| Gate before the act | For irreversible work, after-the-fact acceptance can only detect, never prevent | Change plan reviewed before it runs; gate placement decided by risk |
| Reporting regime | Failures leave nothing behind and the same error recurs | Every task writes a report, complete logs are kept, and triage routes them to one handler |
| Data classification matrix | Sensitive data leaving the controlled boundary unnoticed | Five classes cross-referenced against provider jurisdiction; the highest class never leaves the network |
| Handling boundary | Credentials passing through automation and widening the exposure | AI produces the referencing structure; people supply the credential value |
| Check scripts | A rule written in a document is only an expectation | Criteria that leave no room for judgement are written as scripts, run before work and before delivery |
Change Gates and Handling Boundaries
Irreversible work has a gate beforehand: automation first produces a change plan, an acceptance role from a different model family reviews and approves it, only then is it executed, and afterwards the resulting state is verified. Types that cannot be rehearsed automatically — physical-layer work, boot-stage settings, appliance wizard installations — go through a written change plan instead, and may not skip the step.
Credentials and secrets have a separate handling boundary: AI produces the referencing structure, people supply the credential itself. The test is whether, if this secret leaked, the holder could impersonate someone — anything that can impersonate a person or a machine is an access credential and is generated by a person; anything that is merely a service-to-service password is an application secret, which AI may generate on the control host provided its value never enters any conversation, report or version control.