NCC observes the state before and after a network change under one fixed plan, evaluates it with deterministic rules, and issues one NCC certificate per change — signed, backed by trusted time and a transparency proof. The recipient verifies it without registering.
The domain is authenticated, and the before/after conditions, observation window and pass criteria are bound to the request.
Under a signed job, DNS, TCP, TLS and HTTP are observed strictly within the approved scope.
Version-pinned rules return PASS, FAIL or INCONCLUSIVE. Only PASS proceeds to issue.
The certificate is digitally signed and bound to a verified timestamp and a transparency record.
Anyone can check tampering and authenticity via the public URL or an offline package.
Entry points: Portal, API, OAuth and MCP — the same authorisation and limits apply everywhere. Trusted time is provided by PP-TSA from the same series.
In place of “change completed” plus screenshots, you hand over one verifiable NCC certificate.
Pass or fail is decided only by the plan and rules fixed in advance. AI is limited to explaining results and plays no part in the verdict.
Recipients verify signature, time and transparency at a public URL, without an NCC account.
Completion reports lean on the operator's own logs and screenshots. The receiving side has no way to confirm that it was really checked, at that time, under those conditions.
Logs and captures can be fixed up afterwards by whoever made them. What clients and auditors want is confirmation independent of the operator.
“We confirmed it connects” leaves no record of when, from where, what was checked or against which criteria.
A report you cannot verify pushes trust back onto the individual who wrote it.
Each row states one claim and its limit. Click a row to open the detail.
The target domain is authenticated by an HTTPS challenge. The certificate binds to the authenticated target and to the conditions, window and criteria fixed at request time.
Issuing about someone else's domain, and later disputes over which target the check concerned.
An NCC certificate shows that observation ran against an approved target under approved conditions, was evaluated by fixed rules, and was issued in a tamper-evident form. It does not automatically warrant that the change itself was appropriate, that future availability holds, or that audit or certification standards are met. INCONCLUSIVE is never treated as PASS.
Register with an email address and an environment for your organisation is created on the spot.
Pick one to match how many certificates you issue. You can change it later.
Authenticate the domain via an HTTPS challenge, fix the before/after conditions and criteria, and submit.
If observation and evaluation PASS, the certificate is issued. Hand it over as a public URL or an offline package.
Request and issue from the Portal, or via API, OAuth and MCP. Every entry point applies the same authorisation and limits, with API keys, audit logs and the other management features included.
From the public ID alone, a browser verifies signature, key, time, transparency and revocation state. An offline package supports verification where no network is available.
Not a record for your own files — it exists to hand certainty to the other side.
Deliver completion to customers as a verifiable certificate, ending the back-and-forth over whether a report is genuine.
Issue for yourself, and manage invited customers, issue volumes, plans and billing under one roof.
Receive completion of outsourced changes as independent observation plus rule-based verdicts, not the contractor's own report.
Present change-management evidence — when, what and against which criteria — in a form third parties can verify.
Whether a certificate is trusted depends on what is observed and how verdicts are reached. Both are defined precisely from the start.
Observation runs only against authenticated targets, within what the signed job permits. There is no probing beyond that scope.
Pass or fail is decided deterministically by version-pinned rules. AI is limited to explanation and has no part in the verdict.
PASS, FAIL and INCONCLUSIVE are returned as distinct outcomes. An inconclusive check is never counted as a pass.
Portal, API, OAuth and MCP all apply the same authorisation and limits, with two-factor authentication, API key management and audit logs.