Can a service's own field decide whether a requirement applies? A documentation census of nine APIs
Per public documentation (2026-11-02), exact list matching on a service's own field works directly in 5 of 9 services, all on label or enumeration fields (6 of 9 without one assumed exclusion); 8 of 9 need a projection of a list of objects.
MeasurementWhere does it stop?Working note
- Designed for
- Documentation census testing the portability of the guard's required-read rule: which fields nine services return on a single read of the action's object could decide whether a requirement applies.
What was tested
For nine services (GitHub, GitLab, Bitbucket Cloud, Jira, Linear, Shopify, Stripe, Cal.com and Google Calendar) we read public API documentation, asking which field on a single read of the action’s object could decide whether a requirement applies. We also read the code of the guard’s rule, which uses exact list equality. No service was called.
What we observed
Exact list matching works directly in 5 of 9 services, all on label or enumeration fields; 6 of 9 have a direct string-list field, one excluded by an assumption about its guest list. 8 of 9 need a projection of a list of objects, and 5 of 9 decide by a scalar. The code reading found a silent defect: a list of objects turned the rule off on every action. It now answers “undecided”.
What this means for Heimdall
A portability limit of the rule as built: wider use needs projection, a prefix operator, scalar handling and a completeness rule. It bears on opaque values compared by equality and inclusion.
Limits
Documentation only, as of 2026-11-02, and not archived; several cells are assumptions. That all nine fit the extensions is a design claim.
What remains open
Archive the documentation; build the extended form.