Data contracts and the attribute registry
Declare the attributes your services may send. The contract pipeline stage then enforces the declaration on every log, span and metric point before storage. Managing the registry needs the ManagePipelines action.
The registry
POST /v1/projects/{p}/attribute-registry declares one attribute:
Field | Values |
|---|---|
|
|
| attribute key; a trailing |
|
|
|
|
|
|
| free text |
GET lists (cursor pagination, ?signal=), PATCH|DELETE .../{id} change or remove an entry, POST .../import takes a YAML document or JSON array of at most 2,000 entries (a duplicate rejects the whole batch). A project holds at most 5,000 entries. Every change is audited (attribute_registry.create|update|delete).
Enforcement
Add {"type": "contract", "enforce": true} to the pipeline. Per attribute:
pii_class = secret: the value is always removed, whatever the mode.pii_class = piiwith moderedact: the value is replaced by a salted SHA-256 (hex). The salt is per project, so equal values hash equally within a project (joins work) but cannot be reversed or compared across projects.Wrong type:
warncounts it,dropremoves the attribute,quarantinesends the whole record to the DLQ with reasoncontract:<key>,redactreplaces the value with[contract].Undeclared keys follow the project setting
PUT /v1/projects/{p}/settings/contracts{"undeclared": "allow" | "warn" | "drop"}(defaultallow).
With enforce: false nothing changes; violations are only counted, so you can watch the effect before turning enforcement on. The registry is read by the worker with the pipeline config (cached for 30 seconds).
Seeing violations
Stage stats report the outcomes contract_warn, contract_drop, contract_quarantine and contract_redact. Per-key counts are written to attr_bytes_1d.violations; GET /v1/projects/{p}/attribute-registry/violations?from&to returns the top keys.