Skip to main content

​
STIR/SHAKEN evidence-to-posture crosswalk

Three pages on this tree each own one STIR/SHAKEN dimension, and none of them says how the evidence side meets the posture side: This page is the crosswalk between what is staked in production — the origination-level attestation behaviour Orbit treats as a correctness invariant — and the posture you own, down to the CLI commands that verify each rung and the reporting policy that measures all of it.
Everything here is a tenant-owned control surface. Orbit resolves the level, signals it, and records what you set; it does not mandate a posture for you, and regulatory compliance for your traffic stays with you and your counsel. This page is not legal advice.

​
Compliance posture overview: from the shipped behaviour up

The system-level behaviour this posture rests on has one sentence: Every outbound leg Orbit originates is resolved to A, B, or C against your number state, and that level is signalled to the signing softswitch — no outbound origination surface ships without it. That is not a marketing claim. It is an enforced invariant: the platform pins every outbound origination surface — click-to-call, transfers, conference dial-out, verification calls, SIP-trunk originations, dialer pacing, virtual-hold callbacks, and outbound voice entry points — to resolve the caller ID through the ownership-and-certificate resolution and stamp the resolved level onto the outbound INVITE. A new outbound dial surface that forgets to resolve its level fails closed in the platform’s test layer before it can ever reach production. Downstream, the difference is material: C-attested calls are the ones carriers label “Spam Likely,” and field answer rates between A- and C-attested traffic differ by an order you cannot buy back downstream. The rest of the posture is yours. Attestation levels are earned by the attestation relationship you provision against each caller ID — Orbit computes the level from that relationship; it never stamps a default alongside it. Whichever outcome you want to improve, the ladder Orbit can resolve is: Work that ladder top-down only. Every rung below the one you intend to touch is a fallback for what the rung above could not close — precisely the sequence the posture guide’s worked sequence walks a campaign through. Nothing on this page is a gate at dial time: the policy fields classify what your posture snapshot reports; they never reroute a call or raise what gets signed.

​
Key controls, down to CLI verification

Each control below names the public endpoint it covers, the CLI read-back that proves it took, and the reporting surface that watches it afterward. Work them in the posture-guide order; read back each one before trusting the next.

​
1. Provision ownership or delegate coverage per caller ID

Ownership and delegation are the only levers that move a level. Classify every number a campaign dials from:
The snapshot’s originating.numbers[] lists each of your originating numbers with its current source (owned, leased, or absent from your resolution set) and applied level. A number the campaign intends to present that shows at C — or never lists there — is the one that needs ownership (purchase or port it into Orbit) or an ATIS-1000092 delegate certificate (PEM chain from your service provider):
Re-read the posture after the write: the endpoint is partial (422 VALIDATION_ERROR on bad coverage; DELEGATE_CERT_LIMIT first when the registry is full), every successful write lands in your audit log, and a certificate’s lifecycle — pending, expired, revoked — moves covered numbers back to their ownership-based level (C) on its own. Re-verify after a revoke or expiry; the registry read-back is the evidence, not your recollection of a certificate you registered once.

​
2. Verify the signalled level on the wire

Between Orbit and the signing softswitch, the level travels on the outbound INVITE as the custom X-Devotel-Attest: <A|B|C> SIP header — the same value downstream reporting reads back to you. What you assert it was signed at becomes verifiable end-to-end in three moves:
  1. Resolve from the posture snapshot (GET /api/v1/compliance/attestation/posture) what that number should attest at.
  2. Place a call, and read the per-call attestation result stamped onto the call record in your dashboard’s call detail or the attestation-classification field on the CDR webhook.
  3. Compare the two — and reconcile any gap at the downgrade troubleshooting page, which walks the root causes in the order they fire (ownership ceiling first, certificate lifecycle second, registration reject third, per-number branded-calling override fourth, carrier coverage fifth).
The header-in-the-middle is the load-bearing fact. It is what turns “ownership-first, then certificates, then brand and CNAM” from an editorial convention into a verifiable chain: signalled level ↔ signed PASSporT ↔ per-call reported result. And it is the same stamping every origination surface is pinned to — which is why this crosswalk treats silence in reporting, never a tampered path through the network, as the only shape the gap can take.

​
3. Set the reporting policy deliberately

The policy at GET/PUT /api/v1/compliance/attestation/policy declares the posture you operate under and drives how posture and analytics classify your traffic. Set all three of its halves intentionally:
  • target_attestation — the minimum your originating numbers should meet. A write patches: fields you omit keep their values, a 422 VALIDATION_ERROR on a bad one, every write audited.
  • downgrade_handling: "alert" — the setting that makes below-target numbers surface to your team instead of recording silently under monitor.
  • inbound_min_verification + flag_unverified_inbound — the floor inbound signing is measured against in your 30-day verification summary, and whether unsigned or failed-verification arrivals are classified as spoof_risk rather than merely unverified.
Then read the snapshot back (the GET in step 1) and treat originating.summary.below_target as the to-do list: every number on that list is unresolved by ownership or certificates. When a new outbound dial surface (a campaign, a new API integration) appears in that list uninvited, it is almost certainly dialling from numbers whose ownership-and-certificate relationship was never provisioned — the fix lives in step 1, not the policy form. verified_rate on the inbound half of the same snapshot reads null (and not zero) when there was no inbound traffic in the window — so “no calls” never masquerades as “0% verified.”

​
The certificate, and how the softswitch signs

Two boundary conditions structure who can move what, and they are worth stating plainly on this page too:
  • Orbit never signs a PASSporT. The platform computes the level and signals it on the outbound INVITE. Devotel’s wholesale softswitch — the carrier of record every outbound leg terminates on — holds the STIR/SHAKEN signing certificate and signs at that level. No path through the platform lets a call sign above what it resolved to: the softswitch will not sign higher than the level it is signalled, and the level it is signalled is resolved from your number state, not from anything on the call itself. Holding a stolen platform credential cannot raise what signs through it.
  • Delegate certificates cap at B. A self-registered ATIS-1000092 chain raises the covered numbers from C to B and never further. Full (A) attestation stays reserved for numbers owned through Orbit — treating a self-registered artifact as A would let anyone spoof full attestation for arbitrary numbers.
One real carve-out exists above the tenant policy layer, on its own track. The US federal TCPA voice dialing-window guard is the one platform-global, always-on hard guard: an unresolvable recipient timezone blocks the dial, and it accepts no tenant toggle. It is not part of this posture — it does not raise, classify, or report an attestation level, and no posture rung here mitigates or interacts with it. It is named on this page only because it is the one place a dial stops on a compliance check you do not own; every posture you set above, including the inbound floor, still reports rather than refutes. What branded calling and CNAM do with the levels you settle on lives on the branding surface — registered carriers can render your verified brand on A-attested numbers, CNAM names the number for the fallback label everywhere else, and neither raises an attestation level. Wire them only after the ownership-certificate ladder above has done its work, per the posture guide’s sequencing — brand on a B-certificated or leased traffic drops the RCD payload on the call, so paint last.

​
Keep the sister pages untouched

The crosswalk above is deliberately a bridge — the model definition lives at The attestation model, the endpoint-by-endpoint semantics at STIR/SHAKEN attestation, and the sequenced assembly at The posture guide. Everything on this page should remain only a crosswalk: any change the team needs to make to a knob, a verbatim rule, or a step order gets made on the sister pages, never duplicated here.