# Inventory Security & Venue Verification

How a screen becomes sellable inventory on Trillboards, what blocks it, and how a
demand partner can verify our delivery without trusting our reporting.

This page is the plain-language companion to three machine-readable references:
the [Partner API](https://api.trillboards.com/docs) (registration contract), the
[monetization requirements reference](https://api.trillboards.com/docs/monetization-requirements)
(the gate, code by code), and the
[proof-of-play specification](https://api.trillboards.com/docs/proof-of-play)
(independent verification).

---

## The short version

Our content-management app is free and open — anyone can install it on any
screen. **Installing the app does not create inventory.** A screen becomes
monetizable only after it clears an automated eligibility gate and a human
review, and it stays monetizable only while it keeps producing venue-shaped
telemetry.

If you are evaluating us for supply quality, the two things worth your time are
§3 (the monetization gate, which is machine-enforced and publicly documented)
and §6 (cryptographic proof of play, which lets you audit us without taking our
word for anything).

---

## 1. Two supply routes, two governance models

**Contracted networks.** Established operators integrate our ad-serving stack
into their own players under commercial agreement, with diligence performed at
the network level. For this inventory we declare the **partner's** original
bundle ID to demand — never ours — so the supply chain stays attributable
end-to-end. Every declared bundle appears in
[`trillboards.com/ads.txt`](https://trillboards.com/ads.txt) and
[`app-ads.txt`](https://trillboards.com/app-ads.txt), with ownership in
[`sellers.json`](https://trillboards.com/sellers.json).

**Self-registered venues.** Independent businesses — gyms, restaurants, bars,
laundromats, convenience stores — that sign up directly. This is the long tail,
and it is governed per-screen by the gates below before anything is sellable.

## 2. Registration binds a screen to a physical device

A screen cannot be registered in the abstract:

- Registration must bind to a **live device already displaying a pairing code**.
  A record with no real device behind it cannot be created.
- The database enforces **one device, one screen**. A second registration
  against the same device is rejected outright.

That second constraint is why an impression multiplier cannot be built on our
stack. On networks where several media players sit behind one physical display,
the same audience can be billed several times over and nothing downstream can
detect it. Here the binding is one-to-one at the data layer.

Registration also requires a structured record — location (`lat`/`lng`,
address, city, state, country, timezone), venue classification (category,
environment type, placement), display geometry, mobility type, and venue
photographs. The full contract is published as `POST /v1/partner/device` in the
[Partner API reference](https://api.trillboards.com/docs). Physical dimensions
are plausibility-checked at the API boundary.

## 3. The monetization gate is machine-enforced and publicly documented

Every device registration and lookup returns a `monetization_status` and a
structured `requirements` object, modeled on Stripe's
`account.requirements.currently_due`. Rather than silently accepting a
registration that can never serve, the response states exactly what is missing.

| Status | Meaning |
| --- | --- |
| `ready` | Coordinates present **and** venue classified. Monetizable. |
| `limited` | Not yet classified, or no coordinates of its own yet and listed in inventory feeds only at its operator's declared fleet market location. Servable, with reduced targeting. |
| `blocked` | Cannot serve. |

Blocking conditions include a screen whose submitted address **could not be
geocoded to real-world coordinates**, and a screen whose **automated venue
classification permanently failed**. A mobile screen that has never reported a
genuine GPS fix is also blocked, unless its operator has declared the fleet's
market location: inventory feeds then list it at that market (`limited`), and
geo-targeted demand waits for its own fix.

Each condition has a stable code, a documented cause and a documented
resolution path. The canonical, always-current list lives at
[api.trillboards.com/docs/monetization-requirements](https://api.trillboards.com/docs/monetization-requirements)
— a reviewer can read the blocking codes off a live API response rather than
taking a policy description on faith.

## 4. Human approval, default deny

The automated gate is necessary, not sufficient. Every self-registered screen
begins **outside** the sellable pool and is reviewed by our team before it
enters it.

An unapproved screen is not a screen that bids and loses. It is excluded from
every inventory feed, every DSP-facing endpoint and every SSP export we
publish — demand never sees it. Approval can be revoked, and a screen-level
kill switch removes inventory immediately.

## 5. Venue verification against submitted evidence

Venue claims are checked against evidence rather than accepted as declared:

- **Photographs are machine-graded** for whether they depict a real commercial
  display in a real venue. Submissions that do not are rejected.
- **Venue type is independently classified** from the submitted evidence, then
  mapped to the OpenOOH taxonomy — the same taxonomy Google and the IAB use to
  distinguish DOOH from CTV.
- **Location, venue type and device attestation travel in the bid request**,
  alongside IP, so a buyer can target and audit on the same fields we verified.

## 6. Proof of play you can verify yourself

Every proof-of-play record is signed **on the device** with an Ed25519 key held
in a hardware-backed keystore, and is verifiable by any third party against a
public key we publish openly.

| Resource | URL |
| --- | --- |
| Public verification key | [`/v1/advertiser/proof/.well-known/public-key`](https://api.trillboards.com/v1/advertiser/proof/.well-known/public-key) |
| Specification | [api.trillboards.com/docs/proof-of-play](https://api.trillboards.com/docs/proof-of-play) |

Fetch the key, rebuild the payload as
`version.timestamp.adId.impressionId.screenId.deviceId`, and verify the
signature. Any delivery record we hand you can be checked independently. If it
does not verify, we did not serve it.

## 7. Why a residential screen cannot quietly become inventory

The failure mode this page exists to address is a room full of devices
monetized as venues. Beyond the gates above, that pattern does not survive
contact with our measurement layer.

Our screens carry on-device AI that measures who is physically in front of the
display, and ads are served against measured presence. A living room does not
produce venue-shaped telemetry: no unique-visitor churn, no crowd, no dwell
distribution, no foot traffic pattern. Inventory that cannot produce that
signal is visible to us as an anomaly rather than invisible as a line in a
spreadsheet.

This is the structural difference between our supply and an inventory file of
declared venue types. On a static file, "is this screen really in a bar?" has
no answer after onboarding. Here it is answered continuously, on every
impression, in a record the buyer can verify.

---

## Snapshot

Figures below are a point-in-time snapshot, refreshed periodically. The
mechanisms above are the durable commitment; these numbers illustrate that the
gates carry real load.

*As of 5 August 2026:*

- **24,691** approved screens; **1,065** registered screens held unapproved and
  earning nothing; **92** deactivated after review
- **496 of 4,136** graded venue photographs rejected as not depicting a
  qualifying screen
- **11,859** screens venue-classified from submitted evidence rather than
  self-declaration
- Of screens transacting programmatically in the trailing 30 days, **99.2%**
  carried lat/long and **99.97%** a classified venue type in the bid request
- **4,240** sensing-equipped screens; **28.6M** measurement windows; **2.02
  billion** face observations recorded to date

---

## Contact

Quality, compliance or supply-path questions: **api@trillboards.com**.

We are able to provide demand partners with a dedicated seat drawn only from
the verified pool, so that inventory which has not cleared these controls
cannot appear in what you resell.