Start building with AI in minutes.
Read more
Our values
The commitments we operate under
Values are only useful if someone can hold you to them. The five below describe how Pladinum operates as a matter of policy rather than intention, and each one corresponds to a control, a document, or a published record that customers can inspect without asking us first.
Five commitments, and the evidence behind each
Where a commitment cannot be demonstrated, it does not belong on this page.
1
Accountability sits with the engineers
Support is delivered by the engineers who administer the platform, without an intermediate triage layer. The person assessing a case holds the access and the authority to resolve it, which removes the handover delay that dominates tiered support models and shortens the interval between a problem being reported and a fix being applied.
2
Every production change is reversible by design
No change capable of affecting a live service proceeds without a verified restore point in place beforehand. Rollback is therefore a controlled procedure with a predictable duration rather than an improvised recovery, which is what allows security patches to be applied promptly instead of deferred out of caution.
3
Customer authorisation precedes every cutover
Environments are replicated, never relocated. The source platform remains operational throughout a migration, and DNS is changed only once the customer has validated the result on a temporary address and confirmed in writing. The decision to switch is therefore made against a tested outcome rather than a projected one.
4
Published metrics are measured, not marketed
Availability figures and incident history are drawn from monitoring data and published in full, including the periods that do not flatter us. Where a figure cannot be substantiated it is not published at all, which is why our status page carries the record rather than a summary of it.
5
Leaving is as documented as arriving
Customers retain ownership of their data and can export a full copy at any point during the agreement. Departure is treated as a supported procedure with the same assistance as onboarding, on the basis that infrastructure chosen freely is worth more than infrastructure that is difficult to leave.
Where these came from
We review them when our practice changes, and we remove any commitment we can no longer evidence.
Each commitment on this page originates in an operational decision rather than a positioning exercise. Restore points became mandatory after we concluded that the ability to reverse a change matters more than the speed of applying it. Written approval before cutover became policy because a migration that surprises the customer is a failed migration regardless of its technical outcome.
Fernando García Moreno
System Engineer
Hold us to it
Our service levels, incident history, and operating procedures are published rather than described on request. Review them, then tell us what you are running and we will set out precisely how it would be operated.