> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# STIR/SHAKEN evidence-to-posture crosswalk

> The bridge between the attestation behaviour Orbit stakes its correctness on — every outbound origination surface resolves your caller ID's level and signals it to the softswitch — and the tenant-owned posture your organization actually operates.

# 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:

* [The attestation model](/concepts/stir-shaken-attestation-model) defines
  the levels and the signing model.
* [STIR/SHAKEN attestation](/channels/voice/stir-shaken) documents the
  endpoints and the verbatim resolution rules.
* [The posture guide](/compliance/stir-shaken-posture-guide) sequences the
  controls into a working order.

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.

<Warning>
  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.
</Warning>

## 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:

| Posture rung                                                                           | What you provision                               | Level your caller IDs resolve to |
| -------------------------------------------------------------------------------------- | ------------------------------------------------ | -------------------------------- |
| **Own** the number through Orbit (purchased or ported)                                 | Ownership against the calling org                | **A**                            |
| Register a [delegate certificate](/compliance/attestation) covering an external number | An ATIS-1000092 chain from your service provider | **B** (hard cap, never A)        |
| Use a leased [pool assignment](/numbers/pools)                                         | An active lease in the tenant's pool             | **B**                            |
| None of the above                                                                      | Nothing to resolve against                       | **C**                            |

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](/compliance/stir-shaken-posture-guide)
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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/attestation/posture" \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

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):

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/attestation/delegate-certs" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "friendly_name": "Client campaign caller-ID coverage",
    "certificate_pem": "-----BEGIN CERTIFICATE-----\n…\n-----END CERTIFICATE-----",
    "covered_numbers": ["+14155551234"],
    "not_before": "2026-09-01T00:00:00Z",
    "not_after": "2027-09-01T00:00:00Z"
  }'
```

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](/troubleshooting/stir-shaken-attestation-downgrade)
   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:

```bash theme={null}
curl -X PUT "https://api.orbit.devotel.io/api/v1/compliance/attestation/policy" \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_attestation": "A",
    "downgrade_handling": "alert",
    "inbound_min_verification": "B",
    "flag_unverified_inbound": true
  }'
```

* **`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](/concepts/stir-shaken-attestation-model), the
endpoint-by-endpoint semantics at
[STIR/SHAKEN attestation](/channels/voice/stir-shaken), and the
sequenced assembly at
[The posture guide](/compliance/stir-shaken-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.

***

## Related references

* [The STIR/SHAKEN attestation model](/concepts/stir-shaken-attestation-model) —
  the concept anchor behind the levels, signing vs. signalling, and the
  claims-vs-closes row of the model table.
* [STIR/SHAKEN attestation](/channels/voice/stir-shaken) — the
  level-resolution semantics, the policy fields, the posture snapshot,
  and the verbatim limits.
* [Assembling a STIR/SHAKEN outbound posture](/compliance/stir-shaken-posture-guide) —
  the sequenced assembly this page crosswalks against, with the worked
  campaign sequence.
* [Attestation posture](/compliance/attestation) — the delegate-certificate
  registry, the two policy levers, and the posture snapshot.
* [Attestation downgrade troubleshooting](/troubleshooting/stir-shaken-attestation-downgrade) —
  the fix runs when a level reports below your target, ordered the way
  the root causes fire.
* [Error codes](/reference/error-codes) — `DELEGATE_CERT_LIMIT`,
  `DELEGATE_CERT_DUPLICATE`, `INVALID_CERTIFICATE`, `INVALID_COVERAGE_RANGE`
  on the two write endpoints.