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.
Observation covers DNS, TCP, TLS and HTTP, strictly within the approved scope. The executing node, times and fingerprints of raw evidence are recorded.
Claims about results never observed, probing outside the approved scope, and after-the-fact swapping of observation records.
Normalised observations are evaluated by fixed rules, returning PASS, FAIL or INCONCLUSIVE. The same input yields the same result. AI is limited to explanation.
Verdicts at an operator's discretion, ambiguous results waved through, and verdicts that change on re-evaluation.
The canonical certificate carries a digital signature (ES256 detached JWS). Changing a single character makes verification fail.
Post-issue edits, forged certificates, and disputes over what was actually issued.
A signed timestamp from PP-TSA, the same series, is bound in. The time is not the issuer's own claim.
Backdating, and relying on the issuer's word for when the check happened.
The certificate ships as seven artefacts — canonical JSON, signature, time response, transparency proof, manifest, offline package and PDF — and verifies in a browser from the public ID alone.
Silent withdrawal or replacement of issued certificates, and verification that depends on asking the issuer.
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.
No. Opening the public URL in a browser verifies signature, key, time, transparency and revocation state. Offline-package verification is also supported.
Signing up with an email address and choosing a plan. There is no sales process and no prior screening.
Not in the verdict. Pass or fail comes from a deterministic evaluation by pre-fixed rules, and the same input yields the same result. AI only helps explain the outcome.
No. It shows that observation ran against the approved target and conditions, was evaluated by fixed rules, and was issued tamper-evidently. The soundness of the change and future availability are separate matters.
No certificate is issued. INCONCLUSIVE is kept distinct from both PASS and FAIL and is never rounded up to a pass. You can revise the conditions and request again.