burstdocsDelivery and verification
Milestones
| Stage | Deliverable | Exit evidence |
|---|---|---|
| 0: decisions | Confirm participation, workload, tenancy, trust ownership and data guarantees | Approved decisions and threat model; measurable availability/recovery targets |
| 1: identity | burstauth, burstsecurity, principal registry and enrollment | Invalid issuer/audience rejected; bootstrap replay rejected; certificate rotation and revocation exercised |
| 2: network and RPC | burstnet directory, burstrpc schemas, authenticated three-node network | Cross-network calls denied; relay works without inbound ports; deadlines and retry deduplication verified |
| 3: contracts | Starburst evaluator, publication and central enforcement | Deterministic fixtures; resource-limit failures deny; stale versions cannot commit; deny precedence verified |
| 4: data | Encrypted object storage, placement, repair and expiry | Required acknowledgments enforced; corruption detected; node loss repaired; partition cannot bypass policy |
| 5: applications and UI | Isolated Go/Node/Python workers, login, network/node views and BurstSpace | Worker egress restrictions; service grants; tenant isolation through UI and APIs |
| 6: operational readiness | Backup/restore, key rotation, audit and incident procedures | Restore honors tombstones; revoked peers fail; recovery targets measured; deletion backlog visible |
Build one vertical slice first: human login, create a space, enroll three nodes, publish a contract, upload an encrypted object, read through a group grant, revoke access, then expire and delete the object. Add public participation only after separate admission, Sybil resistance, resource accounting and malicious-provider analysis.
Required design artifacts before coding
Define Protobuf/HTTP schemas, stable identifiers, grant and contract schemas, metadata transactions, certificate profiles, enrollment states, data manifests, error codes and policy inputs/outputs. Record architecture decisions with alternatives and reversal costs. Decide operational limits through load measurements, including object sizes, concurrency, evaluation budgets and revocation freshness.
Acceptance scenarios
- A node with a valid certificate but no membership cannot connect to a network.
- A reader in one space cannot address another space's object or wrapped key.
- Revocation terminates access within the documented lease bound; authority loss denies fresh access.
- A contract requiring three distinct failure domains rejects a write when only two exist.
- A retry after a lost response returns the original mutation outcome.
- A malicious contract cannot read host files, call the network or exhaust its assigned evaluation budget.
- A policy update during upload forces commit-time authorization against the new revision.
- A deleted object stays inaccessible after offline-peer return and backup restoration.
- A compromised application cannot obtain unrelated service credentials or unrestricted egress.
These are planned acceptance checks, not tests already executed. The workspace now contains component modules and a tested identity/authorization/policy/encrypted-storage slice. Native TCP/TLS and PostgreSQL-backed lifecycle tests pass; full deployment, application-worker and operational acceptance remain pending. See implementation status.