> ## Documentation Index
> Fetch the complete documentation index at: https://doc.blueapi.ir/llms.txt
> Use this file to discover all available pages before exploring further.

# Secure Model Packaging: Signed Release Manifest

> Signed release manifest schema, JSON example, dependency pinning, offline bundle, and signing chain diagram for secure model distribution.

SecureModelPackaging defines the schema and process for creating cryptographically signed model release packages. This page specifies the manifest format, the signing chain, dependency pinning rules, and the offline dependency bundle required for air-gapped deployment.

## Release Manifest Schema

The manifest is a JSON document that describes the release, its contents, and its cryptographic proof.

```json theme={null}
{
  "version": "1.0.0",
  "model_id": "emep-enterprise-v2-llama-7b",
  "hash": "sha256:a1b2c3d4e5f6...",
  "signature": "base64-encoded-signature...",
  "signed_by": "release-manager@emep.local",
  "dependencies": {
    "torch": "2.1.0",
    "transformers": "4.35.0",
    "vllm": "0.2.2"
  },
  "sbom_ref": "sbom-emep-v2-2024-01-15.json",
  "license": "apache-2.0",
  "created_at": "2024-01-15T09:00:00Z",
  "expires_at": "2025-01-15T09:00:00Z"
}
```

## Field Definitions

| Field        | Type   | Description                                                         |
| ------------ | ------ | ------------------------------------------------------------------- |
| version      | string | Semantic version of the release                                     |
| model\_id    | string | Unique identifier in [ModelRegistry](/tracking/model-registry)      |
| hash         | string | SHA-256 of the model weights archive                                |
| signature    | string | Cryptographic signature of the manifest hash                        |
| signed\_by   | string | Identity of the signer                                              |
| dependencies | object | Pinned dependency versions                                          |
| sbom\_ref    | string | Reference to the Software Bill of Materials                         |
| license      | string | SPDX license identifier                                             |
| created\_at  | string | ISO 8601 timestamp of release creation                              |
| expires\_at  | string | ISO 8601 timestamp after which the release is considered deprecated |

## Signing Chain

The diagram below shows the package contents and the signing chain.

```mermaid theme={null}
flowchart TD
    subgraph Package
        WEIGHTS[Model Weights Archive]
        MANIFEST[Release Manifest JSON]
        SBOM[SBOM JSON]
        DEPS[Offline Dependency Bundle]
        CONFIG[Deployment Config]
    end

    subgraph Signing
        HASH[SHA-256 of Weights]
        SIGN[Sign Manifest with Private Key]
        VERIFY[Verify with Public Key]
    end

    WEIGHTS --> HASH
    HASH --> MANIFEST
    MANIFEST --> SIGN
    SIGN --> VERIFY
    SBOM --> PACKAGE
    DEPS --> PACKAGE
    CONFIG --> PACKAGE
    VERIFY --> PACKAGE[Signed Release Package]
```

## Dependency Pinning

All dependencies are pinned to exact versions. No version ranges, wildcards, or floating references are permitted. The dependency bundle includes:

* Wheel files for every Python dependency
* System library references with expected versions
* CUDA or ROCm runtime version if applicable

The offline dependency bundle is validated against the SBOM before import into an air-gapped environment.

## Offline Dependency Bundle

The bundle is a self-contained archive of all runtime dependencies. It is constructed at release time and verified at import time.

| Check        | Method                                            | Failure Action        |
| ------------ | ------------------------------------------------- | --------------------- |
| Completeness | Every dependency in manifest has a matching wheel | Reject package        |
| Hash match   | Wheel hash matches SBOM entry                     | Reject package        |
| Signature    | Wheel is from a trusted source or signed          | Quarantine and review |

## Expiration and Rotation

Releases expire one year after creation unless extended by a new signed manifest. Expired releases are moved to DEPRECATED status in [ModelRegistry](/tracking/model-registry) and cannot be deployed to new environments. Existing deployments are not affected but are flagged for update during the next maintenance window.

## Integration

SecureModelPackaging is produced by [DeploymentManager](/deployment/deployment-specification) at release time and consumed by [Offline Deployment](/deployment/offline-deployment) during air-gapped transfer. Manifests are stored in [ArtifactStore](/tracking/artifact-registry) and audited via [Model Provenance](/tracking/model-provenance).