See the line the way your customer sees it.
Your monitoring watches the network from the inside. Helix watches the same line from the subscriber’s PC — thousands of probes an hour, exact counts, from the far end of the last mile. When the two disagree, that disagreement is diagnostic. When they agree, the argument is over.
You see your own customers’ lines. Nobody else, and nothing else.
The paragraph we read to every support desk: Once you have proved to us that you run the network, you see the lines of your customers who run Helix on it. If you hold the AS number, a customer’s line appears as soon as they install Helix on it, with sharing on. If you have no AS number of your own, a line appears once the customer adds the account number you issued them, says which of their lines it is and switches sharing on — or enters a claim code you gave them, which does all three. Either way they can switch it off at any time: you lose visibility on the next query, and nothing but the customer ever switches it back on. You will see latency, packet loss, outages and speed tests for their line — not their browsing, not what they use the connection for.
Two gates, and they are separate
Consent asks whether this subscriber’s sharing is on and has not been switched off. Scope asks which of that subscriber’s connections you may see. Both are live database predicates evaluated on every read, so revocation takes effect on the next query rather than on the next sync.
Both fail closed. Each lives in exactly one module so that widening either one shows up in a code review and breaks a test.
What scope means if you have no ASN
For an AS operator, scope is your ASN: a customer who also runs Helix on an office line served by someone else is not in your view and never will be.
For a reseller or a carrier-grade-NAT operator with no ASN of your own, scope is the connection the subscriber explicitly pinned to you. Unpinned serves nothing — we would rather show you an empty row than someone else’s customer.
A revoked subscriber disappears
Not greyed out, not marked revoked, not retained as a tombstone. An ISP has no business knowing that somebody used to share with it.
Roles are capabilities, not job titles
Every route asks for a capability. A CRM agent can look up a service ID and read tickets but holds no quality permission at all; billing sees billing. Consent was given for support purposes, so a design that lets a billing clerk browse connection history is a failed design, not a trade-off.
Four screens your desk will actually use.
| Screen | What is on it | What it is not |
|---|---|---|
| Subscribers | One row per live link: service ID, whether the link is confirmed or subscriber-asserted, whether sharing is on, and last-seen when it is | Not a customer list. It is your customers who run Helix and are linked to you — on your own AS number by installing it, without one by adding your account number or entering your claim code |
| Subscriber detail | Loss, latency, jitter, derived outage spans and recent speed tests over 24 hours, 7 days or 30 days — recomputed from raw probe counts, not from stored averages | Not browsing history, not traffic, not per-application data. None of that is ever uploaded |
| Ticket queue | Tickets your own subscribers raised against you, each tagged with the service ID you know them by where they added it | Not a general inbox |
| Ticket detail | The thread, status controls, an owner, internal notes your subscriber never sees, the diagnosis report when one is attached, and escalation to your own upstream provider — laid out for review before anything is sent, because what crosses cannot be withdrawn | — |
A ticket can arrive with its own evidence.
A subscriber-raised ticket can arrive with a diagnosis report attached — the verdict and what argues against it, the recent history, a path walk and the carrier-grade-NAT check — so the first question your desk asks is not “when did this start and what were you doing”.
The number you get is re-aggregatable
Quality reads return counts and histograms with the vantage point stamped on every value — never a percentage. Ask for a different window and it is recomputed from the raw counts, so two windows you pull can be combined without producing a number that means nothing.
Attribution you cannot backdate
A maintenance window only suppresses fault attribution if it was declared at least 15 minutes before the fault. A window declared afterwards is still recorded, and still shown — hatched, and visibly distinct from a planned one. The rule exists because without it the feature inverts into a retroactive amnesty.
Advisory signals do not act
When a connection sustains more throughput than the plan you provisioned, Helix flags the binding as possibly stale — and unpins nothing. A plan upgrade you have not mirrored yet reads identically, and a background job quietly tearing down a correct link would look exactly like the outage the customer just called about.
Verdicts carry their counter-evidence
Every diagnosis renders what supports it and what argues against it, both, always. Your engineers get to disagree with the conclusion using the same evidence that produced it, which is the only kind of verdict worth sending to a NOC.
Your NMS is the client. Helix never dials out.
Every connection is opened by your system toward Helix over HTTPS. Helix exposes nothing that reaches back into your network, and there is no design in which it makes an outbound call to a hostname you control — that would be a request-forgery primitive, and refusing to build it costs nothing.
A published contract, not a description
The data half of the contract is served as JSON Schema, unauthenticated, so you can generate types instead of copying a document into your repository.
Its governing rule: the schema is never stricter than the receiver. Where Helix tolerates a value rather than refusing it — an over-long label is truncated, a nonsensical rate is stored as absent — the schema says so and encodes no constraint, because a schema that refuses what the server accepts teaches your client to expect refusals that never come.
Telemetry is pulled, never exported
Subscriber telemetry is read per service and time-bounded. It is never bulk-exported and never replicated into a store you operate — because the moment a copy lives in your database, revocation stops being a code guarantee and becomes a contract term.
Binding, confirmation and consent are three facts
You assert the binding between a service and a connection. You confirm the claim. Consent is the subscriber’s: on your own AS number it starts on, and without one it starts when they switch it on or enter your claim code; either way only they can switch it off or back on. Three writers, deliberately: bulk-loading your fleet must not auto-confirm links, and confirming a link must not grant telemetry.
The binding channel carries no personal data at all, which is why it needs no consent conversation. Service IDs must be opaque, and labels must not carry an address, a name, a phone number or an account number.
The rate limit, said out loud
Quality reads are rate-limited. At the contract’s limit a full sweep of ten thousand subscribers takes several minutes, so fleet-wide subscriber-side quality cannot be rendered under this contract — render per device on demand. We would rather you read that here than discover it in production.
What onboarding involves.
Registering takes a minute and grants nothing. You create an organisation with your AS number, and from that moment you can see your own profile, invite your desk and set your service-ID format. You see no subscriber data at all until verification, and no individual subscriber until one of them runs Helix on your network. Registration is an open door onto a gated capability, which is why it does not need to be defended — an unverified organisation sees nothing, so registering cannot be the attack.
-
Verification
Proof that you operate the network you are claiming — a PeeringDB entry, an RIR object or a letter of authority — plus business verification, before any subscriber data flows. Resellers and CGNAT operators without an ASN are onboarded on the pinned-connection model instead.
-
Your service-ID format
We derive the validation pattern for your account numbers from real examples you provide, so a subscriber typing their own account number correctly is not told it is invalid.
-
Desk accounts
Your team is invited with capability-based roles — NOC, support, CRM, billing, read-only — and suspension is enforced at the authentication layer rather than by each route remembering to check.
-
Your first subscribers
They install the agent on a line on your network. If you hold the AS number, that line appears with sharing on. If you have no AS number of your own, it appears once they add the account number you issued them, say which line it is and switch sharing on, or enter a claim code you gave them. Each of them can switch sharing off, and only they can switch it back on. Until somebody does, your subscriber list is empty — and that is the system working correctly.
If your AS number is already registered.
An AS number can be held by one organisation here, so registration refuses a duplicate. That refusal is the one thing on the way in you cannot work around yourself — you cannot register, you cannot verify, and there is nothing to sign in to. So there is a form for it, on the sign-in page, and the refusal opens it for you with what you typed already filled in.
Two situations end up there, and they are different problems:
- Someone else holds your AS number
- Another organisation registered it. That is sometimes a former reseller or a group company, sometimes somebody who typed the wrong number, and occasionally a genuine dispute. Tell us which AS number, who you are, and where the ownership can be checked.
- You have lost access to your own registration
- The account exists and it is yours, but the address it was created with no longer reaches anybody — the colleague left, the mailbox closed, the reset goes nowhere. Same form, second option.
What makes an appeal decidable
Point at something a person can check without taking your word for it. The RIR object for the AS number (RIPE, ARIN, AFRINIC, APNIC or LACNIC), your PeeringDB record, a letter of authority on your own letterhead. Say what it shows and where to find it. An address at the domain the AS record names is itself part of the evidence, so use one if you have it.
We ask for this bluntly because a claim nobody can verify costs you more than it costs us: it waits for a decision that was never possible to make. “It is ours” is not something anybody can act on.
What happens next
It goes to a person. Filing an appeal changes nothing on its own — it moves no AS number, creates no organisation and grants no access. A Helix operator reads it, checks it against the public record, and replies to the address you gave. If you find more evidence, send the form again with the same address and it is added to the same appeal rather than opening a second one.
We will not tell you over that form whether an AS number is held, or by whom. Every submission gets the same answer, because an endpoint that answered differently would be a way for anyone to learn which networks have accounts here — which is a fact about somebody else’s organisation, not ours to publish.
Your own service IDs, and a count of the rest.
Once you are verified, the portal lists the connections on your network whose subscribers share with you. Where a subscriber has added the account number you issued them, the row carries your own service ID — an identifier you already have on an invoice; a line found on your AS number by itself carries a placeholder instead. Either way the list tells you nothing about them you did not already know.
Sharing is the switch that does the work. On your own AS number it starts on; without one, it starts when the subscriber switches it on or enters your claim code. While it is on you can work a fault with the subscriber from their own measurements. When they turn it off, in the desktop app or in their account online, the flow stops on the next query with nothing kept behind — and nothing automatic ever turns it back on.
Two things that list will never be
It is not a roster of machines. There is no device identifier, no agent version per row, no hostname and no address. Those would be handles for computers you otherwise know nothing about; a service ID is a handle you issued yourself, and the difference is the whole reason one is shown and the other is not. Fleet figures for your network appear as aggregates, above the same publication floor the public rankings use.
It is not everyone. Subscribers on your network who run Helix and are not sharing are counted beside the list and never named. The count is there so eleven rows do not read as eleven customers — and they are not named because telling you which of your customers uses Helix and declined would be reporting a person’s decision to the party they declined.
What this does not do yet.
This list is on the public site on purpose. Everything here is real, current, and would otherwise be discovered in week one.
Coverage
- Windows only — no macOS, Linux, mobile or router agent, so mobile-first customers cannot take part.
- The installer is unsigned; every customer sees a SmartScreen warning.
Workflow
- No webhooks and no BSS/OSS connectors — nothing syncs into Sonar, Splynx, UISP or your CRM. Cross-navigation is copy-and-paste on the service ID.
- Scheduled reports arrive by email: every six hours, a digest of which of your sharing subscribers had a bad period, and which of those you had declared as planned work. No portal screen shows past digests yet.
- Ticket email is plain text with a link. Set up SPF, DKIM and DMARC or your filters will eat it.
- Per-hop country is registry country, not geolocation — never show it to a customer as a location.
Run a pilot.
Pricing for ISP organisations is quoted per opted-in subscriber with a monthly minimum. We would rather scope it against your subscriber count than publish a number that does not fit you.