Content-addressed identity
Canonical release content is hashed, producing a stable identity for the artifact operators review and promote.
Deterministic releases
Promote the artifact you reviewed.
Relpin turns each capsule publish into a content-addressed release pinned to its schema context. TEST and PROD receive the governed artifact through approval-gated promotion, not a rebuild from mutable editor state.
Release record
pinned
- ARTIFACT
- sha256:9f2c4e81…d41a1
- PLATFORM SCHEMA
- v41 · pinned
- ORG SCHEMA
- v7 · pinned
- APPROVALS
- bound to artifact hash
identical content re-publishes as a no-op · version records append-only
The release problem
A successful build is not proof that production received the same software.
Internal tools often move through copied configuration, ad hoc rebuilds, and direct environment edits. That makes review evidence difficult to trust and rollback decisions harder to explain.
Release controls
Determinism is enforced at the promotion boundary.
The release path combines immutable identity, environment policy, and apply-time verification.
Approval-bound promotion
TEST and PROD advancement follows explicit approval policy. Re-planning changes the artifact context and invalidates stale approval evidence.
Fail-closed drift checks
Promotion verifies the target schema context before the deployment pointer moves. Drift stops the operation instead of silently weakening the release.
Operating model
Build once. Review the exact unit. Promote through policy.
Capsules keep app code and owned data changes inside one governed promotion boundary.
- 01
Publish in DEV
Relpin records the capsule release, required capabilities, build output, and pinned schema context.
- 02
Review for the target environment
Operators inspect the planned artifact and schema changes before granting the approvals required by policy.
- 03
Apply without bypass
The worker verifies drift and deployment inputs, applies governed schema work when required, then advances the target deployment.
Release evidence
Content-addressed capsule release
DEV → TEST → PROD state machine
Approval and separation-of-duties policy
Immutable promotion event timeline
Release questions
What deterministic promotion changes for operators.
Does Relpin rebuild an app during promotion?
Promotion uses the governed release and deployable build associated with the source environment. The target does not accept mutable editor state as a production release.
What happens when the target schema changed?
Apply-time drift checks stop the promotion when its pinned assumptions no longer match. Operators recreate or re-plan the promotion against the current state.
Can TEST or PROD bypass promotion?
The governed path blocks direct TEST and PROD mutation paths by default. Promotion is the user-facing route for advancing a capsule.
Pinned by default
Make release evidence part of the runtime path.
Build internal tools as real code, then move them through deterministic promotion without losing the artifact operators reviewed.
Open beta · No SLA