Tracking issue for the two regulatory blueprints, which are blocked on the same design question rather than on effort.
The blocker
_blueprints/ holds four entries — AWS, eBay, Stripe, Twilio — and every one is a provider blueprint: a name, a description, a tag, and a gist. That shape does not fit a regulation.
A provider blueprint says "here is how this company runs its API program, learn from it." A regulation blueprint has to say something different, and nobody has decided what:
- The obligations the rule creates, and which are API-shaped
- The standards that satisfy them — FDX for 1033, FHIR/USCDI for HHS
- Conformance: what a compliant API surface actually looks like, and what can be checked mechanically
- Dates: compliance tiers and deadlines, which are the part everyone actually needs
- The gap between claiming compliance and shipping a conformant contract
That last one is the interesting one, and it is the same distinction the Kin Score work turns on.
Why this is worth doing properly
The source material largely exists — the US banking / FDX and healthcare sector work has already been done elsewhere in the network. What is missing is the object model: decide what a regulation blueprint is, build one, then the second is mechanical.
There is also an obvious pairing with #4: an FDX ruleset would give the 1033 blueprint something machine-checkable to point at, instead of prose about compliance.
Tracking issue for the two regulatory blueprints, which are blocked on the same design question rather than on effort.
The blocker
_blueprints/holds four entries — AWS, eBay, Stripe, Twilio — and every one is a provider blueprint: a name, a description, a tag, and a gist. That shape does not fit a regulation.A provider blueprint says "here is how this company runs its API program, learn from it." A regulation blueprint has to say something different, and nobody has decided what:
That last one is the interesting one, and it is the same distinction the Kin Score work turns on.
Why this is worth doing properly
The source material largely exists — the US banking / FDX and healthcare sector work has already been done elsewhere in the network. What is missing is the object model: decide what a regulation blueprint is, build one, then the second is mechanical.
There is also an obvious pairing with #4: an FDX ruleset would give the 1033 blueprint something machine-checkable to point at, instead of prose about compliance.