Record a maintainer for every vendor integration, from the vendor

[jwrosewell]

Nothing in this repository records who maintains any integration. Someone reading it cannot tell whether a vendor integration was written by that vendor or by this project on the vendor's behalf, and those are very different things for anyone deciding whether to trust it.

What was checked and found

There are thirteen registered integrations, listed by builders() in crates/trusted-server-core/src/integrations/mod.rs. Nine of them are another company's product, and #1084 names those nine as APS, DataDome, Didomi, Google Tag Manager, GPT, Lockr, Osano, Permutive and Sourcepoint.

None of the thirteen has maintainer information anywhere. Checked seven ways, all against upstream/main:

• No CODEOWNERS file exists in any of the three locations GitHub reads.
• Nothing in .github/ names an owner. The Dependabot configuration sets no reviewers and the pull request template asks nothing about ownership.
• IntegrationMetadata and IntegrationBuilder in crates/trusted-server-core/src/integrations/mod.rs have no owner field.
• The workspace Cargo.toml has authors = [].
• None of the fourteen pages under docs/guide/integrations/ carries a maintainer, owner or contact field. Most carry a Category, Status and Type header block, though the APS, DataDome and Sourcepoint pages have no such block at all.
• No module-level doc comment names anyone.
• ProjectGovernance.md and CONTRIBUTING.md describe project roles rather than per-integration ownership.

Every one of the nine was written by this project, not by the vendor. From git log on each integration's source file, the authors are prk-Jr, ChristianPavilonis, aram356, vasujain00 and jwrosewell. No commit on any of the nine comes from someone at the vendor whose product it integrates.

How this sits with CODEOWNERS

docs/superpowers/specs/2026-01-15-attestation-design.md already proposed vendor CODEOWNERS entries as a Required item, in its Phase 3, and none of it was implemented. That guidance is worth keeping rather than dropping, because CODEOWNERS is what routes a review request to the right people and what branch protection can require a review from. It is the enforcement half.

Two things about it need stating plainly, so the expectation is right when it is implemented.

A GitHub code owner must have write permission on the repository. Users and teams need explicit write access, and GitHub silently ignores an entry for anyone who does not have it, so a rule naming a vendor without write access looks present in the file and does nothing. Recording vendors as code owners therefore depends on a decision about granting them write access, which is why this has not happened yet.

GitHub's write permission is repository-wide, while a maintainer's remit is not. A vendor maintainer is responsible for their own integration and nothing else, and clearly not every vendor should be changing all of the code. CODEOWNERS expresses that scope for review, because its path patterns request that vendor's review only on their own paths, but it does not and cannot restrict what they are technically able to change. That gap should be closed by the project's own review rules and by branch protection rather than assumed away, and it should be written down so nobody believes a CODEOWNERS entry is a permission boundary. It is a routing rule.

CODEOWNERS is also a single file, in .github/, the root or docs/, rather than one file per vendor directory, so it does not travel with a vendor crate when the integrations move out of core. That is a second reason it needs a companion rather than being the only record.

What we suggest instead, which is what Prebid does

Prebid does not use CODEOWNERS in either of its repositories. It publishes a Maintainer: line in each module's own markdown documentation, required by dev-docs/bidder-adaptor.md, and 582 of 717 module markdown files carry one.

Mirroring that here means adding a Maintainer: field to the header block of each page under docs/guide/integrations/, alongside the Category, Status and Type fields where a page already has them and as a new block on the APS, DataDome and Sourcepoint pages that have none. It needs no GitHub account and no write access from the vendor, it survives the move to vendor crates untouched because the field travels with the module's documentation, and the existing docs format gate already covers those files.

What we are asking for

1. Keep the CODEOWNERS guidance and clarify its scope. Restate it in the attestation spec so it says what a vendor code owner is responsible for, being their own integration's paths and not the wider codebase, and note that it depends on the write-access question being settled. Add that a CODEOWNERS entry routes review and is not a permission boundary, so nobody reads it as one.
2. Adopt a Maintainer: field on every integration documentation page, mirroring Prebid. This is the half that works today, because it needs no write access, and it is the half that travels with a vendor crate when the integrations move out of core.
3. Obtain a maintainer from the vendor for each of the nine. Only one of the nine has a Prebid maintainer address that could be mirrored, which is APS at aps-prebid@amazon.com. Six of the nine have no Prebid module at all, so there is nothing to copy for DataDome, Didomi, Google Tag Manager, GPT, Osano and Sourcepoint, and those contacts have to be asked for.
4. Require a maintainer on any new vendor integration, including #1054, before it merges. When we rework Add managed LiveRamp RampID integration #1054 onto the module seam we will add the Maintainer: line to its documentation page ourselves, carrying the authors as the interim entry and a plain note that a maintainer from LiveRamp still needs to be identified. We are not able to supply that name, only to make its absence visible rather than silent.
5. In the meantime, record the people who actually wrote the code, so the field is never empty and never implies a vendor is maintaining something they have never seen. Interim entries, from git log on each integration:

Integration	Interim maintainers, being the authors
APS	@prk-Jr, @ChristianPavilonis
DataDome	@prk-Jr, @ChristianPavilonis
Didomi	@prk-Jr, @ChristianPavilonis
Google Tag Manager	@prk-Jr, @ChristianPavilonis
GPT	@prk-Jr, @ChristianPavilonis
Lockr	@prk-Jr, @aram356
Osano	@ChristianPavilonis, @aram356
Permutive	@prk-Jr, @aram356
Sourcepoint	@ChristianPavilonis, @aram356

Each interim entry should say plainly that it is an author rather than a vendor maintainer, so nobody reads it as vendor endorsement.

Why this matters

Someone assessing Trusted Server needs to know whether a vendor integration comes from the vendor. An integration written by this project and carrying a vendor's name, with no maintainer recorded, can easily be read as the vendor's own work and their endorsement of it. That is misleading even when nobody intended it, and it is exactly the kind of claim the project should be able to substantiate rather than leave to inference. Recording it costs one line per integration.

---

Produced with AI assistance. The findings were checked against the source at upstream/main and against the public Prebid repositories, and the whole issue needs human review before it is acted on.