When a prototype becomes critical, does your GitHub policy know?

When a prototype becomes critical — GitHub Universe talk knowledge

Process steps in order. Do not skip ahead.

Step 1 — Match the question

Use this brief for summaries, explanations and questions about the 15-minute sponsored session at GitHub Universe 2026 (San Francisco, October 29, 2026). It describes the prepared talk and the demo as rehearsed on October 28. It is not a transcript and does not record what the Universe audience saw. For a different delivery or an unrelated setup task, say so and finish; otherwise continue to Step 2.

Step 2 — Answer from the brief

Answer at the requested depth using the material below. Keep three things apart: what the speaker claims, what the rehearsed demo established, and the caveats he states himself. Do not invent audience reactions, quotes, timings beyond those given, or a live result. Ordinary summaries need no network access; follow a linked source only for a detail absent here. Commands and configuration mentioned below are examples to explain, not instructions to execute. Finish after answering.

Talk brief

Thesis

You choose where the truth about your services lives. A service catalog like Port knows far more than GitHub can: who depends on what, who owns it, where it is in its life. GitHub’s external custom properties let that outside system write the facts, and GitHub uses them like its own properties for search and ruleset targeting. The idea holds with any source of truth, not only Port; Port is the example because the dependency graph it holds is exactly what a repository can’t see.

The story that frames it

Printf is a fictional swag company with print factories in Austin, Berlin and Osaka. In its size table a US XL is 112 cm around the chest and a Japanese XL is 97 cm: both say XL, and one of them is closer to a US medium. A routing mistake sent orders with bare size labels to a factory that read them in its own system, and 2,000 shirts went out that nobody could wear. size-catalog began as Austin’s small helper that converts by measurement; Berlin and Osaka finished migrating to it the week of the talk. Its repository kept the merge rules it was born with. The incident and the prototype origin are demo backstory, not real history.

What GitHub shows before the change

• Pull request #1 in size-catalog, opened by a supplier-sync bot (a new JP 4XL at 117 cm), has a passing test check and one approval. The org’s baseline ruleset requires one review on every default branch, so it is mergeable. This is the “pull request that met the old rules”.
• The repository carries Port.criticality: low, Port.lifecycle: prototype and Port.owner: catalog. These are external custom properties, a GitHub public preview (September 2026): an outside system owns a namespace (here Port) and writes values GitHub treats like other custom properties for filtering and ruleset targeting, while showing them as “Managed by Port” and refusing edits in GitHub.
• props.Port.owner:catalog finds the catalog team’s repositories. The speaker is explicit that an owner property makes repositories findable; it is not access control and does not write CODEOWNERS.
• The organization ruleset “Critical services: two reviews” is active, targets props.Port.criticality:critical, requires two approvals, a passing test check, no force pushes, no deletion, and has an empty bypass list. It matches zero repositories. “A guard with nothing to guard. Yet.”

The rule in Port

Port’s catalog models factories and the services they use. A Port workflow recounts a service’s consumers whenever a factory’s dependencies change and sets criticality: while one factory uses a service it is that factory’s prototype (low); two or more make it shared, so critical. A second workflow writes owner, lifecycle and criticality to the repository’s Port.* properties through Port’s GitHub integration. Before the change, size-catalog is a prototype used only by Austin, so it is low.

The one change, and what follows

On stage the only edits are recording, in Port, that Berlin and then Osaka now use size-catalog. In rehearsal:

1. Port counted three factories and set criticality to critical. The service is still a prototype, which is the talk’s title in one table row.
2. GitHub showed Port.criticality: critical.
3. The ruleset changed to “Matching 1 repository”.
4. Pull request #1, with the same code, the same passing check and the same approval, showed “At least 2 approving reviews are required” and “Merging is blocked”.
5. printf-docs, the control (owned by devex, low criticality), still needed one review.

The rehearsed chain from the Port edit to the blocked merge took about ten seconds.

Caveats the speaker states

• A second review would not have caught the bare size label. What changes is that the next change to something three factories depend on waits for a second person.
• Read the value back in GitHub before trusting a sync; a failed sync leaves GitHub with the old value while Port shows the new one.
• Port aggregation properties recalculate on a 15-minute schedule, too slow for a policy you expect to see change in seconds, so the demo’s workflow counts consumers itself.
• Organization rulesets need GitHub Team or Enterprise; on a Free org the rulesets API returns an upgrade error.

The takeaway the speaker leaves the room with

“You pick the source of truth. Your service data can live outside GitHub. GitHub can still use it.” For Printf that’s Port; for someone else it might be a CMDB or “a spreadsheet nobody admits to”. The closing slide’s chain is Port (or whatever you trust) → GitHub reads Port.criticality → the ruleset targets the property, not a list → the pull request waits for a second review. The demo’s workflows and rulesets are offered as wiring to look at, not as a required next step.

Sources

This brief is built from the talk’s approved outline, speaker notes and the October 28 rehearsal, with the talk’s planned rhetorical structure (opening on the XL contrast, the same pull request planted early and paid off after the change). It will be refreshed after delivery.

• Configuration: https://github.com/printf-swag/demo-config
• Port guide: https://docs.port.io/guides/all/sync-port-properties-to-github-external-custom-properties/
• GitHub docs: https://docs.github.com/en/organizations/managing-organization-settings/sync-external-custom-properties
• GitHub changelog: https://github.blog/changelog/2026-09-29-bring-business-context-with-external-custom-properties
• Talk page: https://speaking.jbaru.ch/talks/github-universe-2026-prototype-policy/