Contracts and data lifecycle

Contract model

A contract is an immutable, signed, versioned policy artifact bound to a network, space and resource class. It specifies owner, group and service IDs; permitted actions; allowed destinations and transformations; durability requirements; residency constraints; retention and expiry; key-release conditions; and audit obligations. Signatures prove provenance, not authorization: publication also checks the signer's current administrative grant.

Starburst embeds Starlark with a small, versioned API. Its host exposes no filesystem, network, process execution or ambient clock. Supply time and identity as explicit trusted inputs. Bound evaluation steps, memory, collection sizes and result size; reject unknown fields and built-ins. Pin interpreter and API versions. Starlark's deterministic, hermetic model is described in the language specification; resource enforcement remains the host's responsibility.

The evaluator returns allow/deny plus obligations. Enforcement services execute obligations; a policy result alone cannot replicate, delete or encrypt data. Evaluation errors, unavailable required context and unsupported obligations deny the operation.

Illustrative contract fields, not an implemented DSL:

api_version: burst.policy/v1
network_id: net_example
space_id: space_example
owner_id: user_example
reader_group_ids: [group_example]
writer_service_ids: [service_example]
flow:
  allowed_network_ids: [net_example]
  allowed_regions: [region_a]
survival:
  replicas: 3
  distinct_failure_domains: 3
  acknowledgment: all_required_replicas
access:
  actions: [read, write]
  require_current_key_authorization: true
expiry:
  ttl_seconds: 2592000
  origin: committed_at

Identity mappings and updates

Store owner, group and service mappings as stable typed IDs in authoritative metadata. Never infer ownership from filenames, email, node location or possession of ciphertext. Ownership transfer requires current owner or recovery authority approval and a transactional audit event. It does not silently grant the new owner historical plaintext access.

Publish through draft, validation, simulation, approval and activation. Persist source digest, signer, schema/interpreter versions and activation revision. Commit policy and active-version pointer atomically. Bind each operation to a policy revision; reauthorize at commit if the revision changes. Rollback creates a new activation event and cannot resurrect expired data or revoked credentials. Emergency network denies override contracts.

Data flow and use

1. Authenticate the writer and authorize create against grants and the active contract.
2. Validate destination, size, classification and available compliant placement capacity.
3. Encrypt with an object data key; store wrapped keys separately under managed key custody. Use tenant-scoped ciphertext digests to avoid cross-tenant deduplication leakage.
4. Transfer chunks to selected peers and verify ciphertext hashes and signed manifests. A hash proves integrity, not ongoing availability or honest execution.
5. Commit metadata only after the contract's required durable acknowledgments. Return a clear failure if placement requirements cannot be met; garbage-collect abandoned staging objects.
6. On read, check current permission and expiry, authorize key release, verify integrity and audit access. Storage peers receive only the authority required to serve ciphertext.

Use application identities and isolated workers for transformations. Grant explicit input, output and egress permissions. Derived outputs inherit input restrictions unless an authorized transformation policy permits a change. Once plaintext reaches a client, policy cannot technically prevent copying or prove approved use. Confidential computing or client-held keys would require a separate threat model.

Survival, expiry and failures

Begin with replication across independent failure domains. Reconcile desired and observed replicas; verify stored chunks, repair losses and alert on degraded durability. Do not claim a durability percentage before measuring failure rates and repair windows. Erasure coding can follow workload benchmarks.

During partitions, deny operations needing fresh authorization or new metadata commits. Existing ciphertext replicas remain available for later authorized reads. Do not accept conflicting offline writes in MVP. Capacity shortages never relax residency or replication constraints silently.

Expiry starts at authoritative commit time. At expiry deny reads and key release immediately according to the bounded lease policy, publish tombstones, stop replication and schedule physical deletion on every known replica. Retain tombstones longer than the maximum permitted offline-peer interval; returning peers must reconcile deletion before serving data. Backup restores replay tombstones before exposure.

Track logical expiry, key destruction, replica deletion and backup expiry separately. Cryptographic erasure requires destruction of every usable wrapped-key copy, including backups. It cannot erase plaintext already exported or keys retained by a malicious party. Legal holds, backup retention, owner-requested deletion and offline-peer deadlines require explicit product decisions; do not promise immediate global physical deletion.

Audit records contain principal, action, resource ID, policy revision, decision, obligation outcomes and correlation ID. Store append-only records with restricted access and retention independent of expired payloads. Alert on failed repairs, denied key releases, revocation lag and deletion backlog.