Skip to content
Registry StackDocsDevelopment (unreleased)

Conventions for module authors

View as Markdown

If you write a service or worker beside Registry Stack, including Base Registry Engine (BReg), preserve each product’s authority and use its released interface. Your module owns its own authorization, state, and recovery; an accepted review or a delivered notification does not grant it source mutation rights.

Use the shared token profile and the token acquisition guide. Configure a separate token provider for each resource, audience, and scope set. The shared SDK authentication facade removes token acquisition plumbing while the selected product still checks its own principal, profile, and permissions.

The client API reference owns the supported language surfaces. Keep private keys server-side and request the scopes the deployment admits.

Handle problems, tracing, and uncertain effects

Section titled “Handle problems, tracing, and uncertain effects”

The common HTTP problem contract owns the envelope and trace relationship. Branch on the owning product’s code and documented recovery action, and keep response trace context for diagnosis. Do not expose raw tokens or upstream transport errors to callers.

Use the product’s idempotency contract for the operation you call. Preserve the original key, body, profile, and revision guards after an uncertain write, then recover or read back its state. An operation that offers no idempotency key must not acquire a retry loop by convention. The shared client rules limit retries; the BReg API and Casework API define their operation-specific effects. Render’s correlation key is not a deduplication promise.

Use the delivery signing contract for exact header and byte rules. Verify the original body bytes before parsing them, compare the signature in constant time, and bind deduplication to the verified delivery identity and payload. A completion wake announces that a result can be read; read that result from its authoritative product and correlate it to the request you accepted.

The deterministic cross-language fixtures come from that owning implementation. Run their exact bytes, key, and expected signatures through your language’s implementation, including the negative cases, before sending or accepting live traffic. The owning drift test ensures the fixtures and signing implementation agree.

The Python reference service combines BReg, Casework, and Messaging over the released client interfaces, with a resource-bound token helper and a completion wake receiver. It is one example composition, not a required set of products. Its README owns installation, local configuration, and the runnable journey.

Use existing Manifest data_services for a real service that serves declared datasets. A worker can use the separate static modules description without a dataset. The Manifest reference owns that metadata contract. Manifest performs no health check, authentication, dynamic registration, or capability enforcement for a described module.