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 (registration contract), the monetization requirements reference (the gate, code by code), and the proof-of-play specification (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 and app-ads.txt, with ownership in 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. 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.

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 — 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.

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.