Signature Verification

Every algorithm published to the AnyBio Marketplace is cryptographically signed by its publishing organization. Entitled customers - and external auditors acting on their behalf - can verify that the algorithm running against their streams matches what the publisher signed.

How signing works

When an algorithm is published, the platform:

1. Computes a SHA-256 hash of the algorithm binary.
2. Signs the hash with the publisher organization's signing key.
3. Stores the signature alongside the algorithm.

At execution time, the platform recomputes the hash and verifies the signature before running the algorithm. Verification is fail-closed: a mismatch causes execution to abort with an audit log entry, not a silent fallback.

The signing key is per-publisher-organization, not per-algorithm. The same public key verifies every algorithm a given publisher has signed.

Public-key endpoint

To verify externally - for example, in an audit pipeline that re-checks algorithm integrity outside the platform - fetch the publisher's public key:

GET /api/v1/algorithms/{algorithmId}/public-key

Returns the public key in PEM-encoded SubjectPublicKeyInfo form:

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEA...
-----END PUBLIC KEY-----

Authentication: any caller that can list the algorithm (the publisher organization itself, or an entitled customer organization) can fetch the public key.

What the key verifies

A successful verification confirms:

• The algorithm binary hasn't been altered since the publisher signed it.
• The signing key belongs to the publisher organization recorded on the algorithm.
• Therefore: the algorithm running against your streams is the same code the publisher submitted.

The public key endpoint is the trust artifact for external verification. Entitled customers don't need to do anything to trigger verification - the platform performs it on every execution - but having the public key available means an auditor can independently confirm what's running.

Algorithm identity

Each algorithm carries:

• A stable algorithmId (UUID).
• A version tag in its method_code (e.g., algorithm:partner_hrv_v2).
• A reference to its publisher organization.

Versions are immutable. When an algorithm is updated, the new version gets a new method code and a new (or rotated) signature. Historical observations keep their original method code so prior analyses remain reproducible.

Why this matters

For clinical and regulated applications, signed algorithms with verifiable provenance are table stakes. The combination of cryptographic signing, fail-closed verification, and a public verification surface gives you a defensible chain of custody from algorithm vendor to observation: the auditor can confirm the algorithm bytes, the platform confirms the algorithm binding, and every output observation carries the algorithm version that produced it.

For non-clinical applications the same machinery is still useful as a tamper-evident integrity check across the algorithm-vendor / platform / customer boundary.