Artifact
Patch Format v1
Signed bytes carry the artifact identity, digest, and capability boundary.
Security and trust
The runtime keeps the final say.
Delivery can be convenient. Acceptance remains exact, signed, bounded, and local to the runtime that executes the patch. The service boundary, data practices, and limitations should be just as inspectable.
Four boundaries, one decision.
Runtime
Exact release checks
The device checks application, release, capabilities, sequence, digest, and signature before acceptance.
Service
Eligibility only
A control plane can filter delivery and record state. It cannot make invalid bytes valid.
Recovery
Signed base rollback
Recovery returns to base without lowering the anti-replay high-water or making an old patch replayable.
Keys do not share a job.
Authentication JWT signing material is separate from Patch Format signing material. Artifact verification remains its own trust boundary instead of inheriting identity from the web session.
Trust boundaries
auth signing key != patch signing key
server session != artifact trust
delivery eligibility != runtime acceptanceOperational controls
Security is also an operating boundary.
Cloud access, delivery, telemetry, and support are governed by the same scoped identity and audit model. The final security schedule, provider inventory, and incident commitments remain subject to the applicable Cloud agreement.
Access
Audience and tenant separation
Customer sessions are authorized against their organization scope. Platform operations use a separate staff audience and capability boundary; a customer session is not a platform credential.
Secrets
Credentials stay out of artifacts
Provider credentials, signing material, verification tokens, and session secrets are not part of the public frontend, project configuration, release metadata, or customer-facing audit views.
Telemetry
Operational evidence with limits
Delivery and installation evidence is used for integrity, support, abuse prevention, and the subscribed usage model. The Privacy Policy describes the categories and retention boundary; it is not a promise of zero device or technical metadata.
Response
Report risk before exploiting it
Report suspected vulnerabilities, compromised accounts, or exposed secrets through support@hyfens.com. See the Support Terms for the support and incident boundary.
Claims with edges are useful claims.
Availability
No cloud requirement for correctness.
A hosted or self-hosted endpoint is a delivery input. Local runtime correctness does not depend on cloud connectivity.
Patch scope
No arbitrary Dart claim.
Hyfens supports a declared subset of ordinary source. Unsupported changes fail closed and require the normal release path.
Device posture
No rooted-device promise.
The current security boundary does not claim protection against a rooted or fully compromised device or compromised signing keys.
Policy
No store approval claim.
App Store, Google Play, legal, privacy, and compliance outcomes require independent review and are outside this product surface.
Put the endpoint where it belongs.
Read how managed and self-hosted delivery share the same identity and authorization model, then review the legal and policy index.