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

# Pack Customization

> Enterprise customization — custom cover pages, branding, custom sections, suppression of default appendices. How to upload templates.

# Pack Customization

The Free and Team default pack design is the recommendation for the vast majority of audit interactions. Customization is an **Enterprise-tier** capability for organisations whose auditors expect a specific layout, whose internal style guide constrains deliverables, or who hand packs through to downstream customers under their own brand.

<Info>
  Customization affects the **PDF** primarily. The ZIP and ReqIF formats remain raw and round-trippable. A customized PDF still satisfies the integrity model — the manifest and signature are unchanged.
</Info>

## What can be customised

| Element                   | Scope of change                                                                                                                             |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cover page**            | Custom HTML/CSS template; org logo, customer logo, project metadata, custom fields                                                          |
| **Disclaimer page**       | Add a customer-supplied disclaimer alongside the canonical Roboticks one; the canonical one is never removed                                |
| **Branding**              | Header / footer logos, colour palette overrides, font selection from a curated list                                                         |
| **Custom sections**       | Insert arbitrary HTML or Markdown sections between the standard sections                                                                    |
| **Section reordering**    | Change the order of standard sections                                                                                                       |
| **Suppression**           | Suppress optional appendices (screenshots, SBOM details, static-analysis full output) — never the manifest or the verification instructions |
| **Page size and margins** | A4 / US Letter / B5; configurable margins                                                                                                   |
| **Locale**                | Date format, decimal separator, table headers in customer's locale (en, de, fr, ja, ko available)                                           |

## What cannot be customised

The integrity-critical sections are immutable.

* **Manifest appendix** — always printed verbatim.
* **Verification instructions** — always printed; auditors must be able to verify.
* **Canonical Roboticks disclaimer** — always present. You can add your own; you cannot remove ours.
* **Standards-derivation tables** — content is dictated by your pinned standards, not customizable.
* **Test result tables** — content reflects actual JUnit data.

This is by design: an auditor must be able to look at a Roboticks pack from any customer and find the same anchors. Customization is a presentation layer over invariant evidence.

## Uploading a template

Templates live at the **Project** level (defaults flow from Organization).

<Steps>
  <Step title="Compose the template">
    Templates are a tarball with the following structure:

    ```
    template.tar.gz
    ├── manifest.json          # Template version, schema, declared sections
    ├── cover.html.jinja       # Cover-page template
    ├── header.html.jinja      # Per-page header
    ├── footer.html.jinja      # Per-page footer
    ├── overrides.css          # CSS overrides applied after the default sheet
    ├── sections/
    │   ├── 01-executive-summary.html.jinja   # Optional overrides
    │   └── 99-custom-section.html.jinja      # New sections (filename ordering)
    └── assets/
        ├── customer-logo.svg
        └── …
    ```

    The Jinja templates have access to the full manifest model as a Python dict. The contract is documented at [`roboticks-sdk/schemas/template.context.json`](https://github.com/roboticks-io/roboticks-sdk/blob/main/schemas/template.context.json).
  </Step>

  <Step title="Validate locally">
    ```bash theme={null}
    rbtk evidence template validate ./template.tar.gz
    rbtk evidence template preview ./template.tar.gz \
      --release v1.4.0 \
      --out preview.pdf
    ```

    The `preview` subcommand renders against a real release without uploading the template — useful for iterating on the design.
  </Step>

  <Step title="Upload">
    **Project Settings → Evidence → Templates → Upload**. Or:

    ```bash theme={null}
    rbtk evidence template upload ./template.tar.gz \
      --project acme-robotics/firmware
    ```

    Uploaded templates are versioned; rolling back is a one-click revert.
  </Step>

  <Step title="Apply to a generation">
    On the **Generate Evidence Pack** modal, pick the uploaded template from the dropdown. From CLI:

    ```bash theme={null}
    rbtk test evidence-pack --release v1.4.0 --template customer-acme-v3
    ```
  </Step>
</Steps>

## Co-branding workflows

A common Enterprise pattern: an OEM integrator generates packs for end-customer programs and hands them to the customer's auditor under the customer's brand.

The recommended setup:

* One **base template** at Organization level with your integrator branding.
* Per-customer **child templates** at Project level that override the cover and header with the customer's logo and palette.
* A naming convention (`customer-{name}-v{n}`) so the pack-generation flow makes it obvious which template is selected.

The Roboticks footer marker is suppressible at Enterprise tier — replace it with your own attribution if your customer's contract requires it.

## Validation rules

Uploads are rejected if a template:

* References missing assets.
* Removes any of the immutable sections (manifest, verification instructions, canonical disclaimer).
* Produces a PDF larger than 250 MB at preview (a defence against runaway template loops).
* Contains executable content (no JavaScript; Jinja-only templating).

These constraints exist because a pack is signed evidence — the rendering process must be deterministic and the output must remain auditable.

## Default appendix suppression

Even without a custom template, you can selectively suppress non-mandatory appendices at generation time:

```bash theme={null}
rbtk test evidence-pack --release v1.4.0 \
  --suppress screenshots,sbom-detail,sarif-full
```

| Appendix                  | Default              | Suppressible                        | Notes                                                         |
| ------------------------- | -------------------- | ----------------------------------- | ------------------------------------------------------------- |
| Screenshots               | included if captured | yes                                 | Large; many auditors prefer the ZIP for these                 |
| SBOM detail               | full table           | yes (summary only)                  | Suppresses per-component rows; keeps counts and CVE summary   |
| SARIF full output         | full per-finding     | yes (severity-grouped summary only) | Useful when the scanner emits thousands of low-noise findings |
| Manifest appendix         | full                 | **no**                              | Required                                                      |
| Verification instructions | full                 | **no**                              | Required                                                      |
| Coverage detail           | per-file             | yes (project totals only)           | Some auditors want totals only                                |

## Next steps

<CardGroup cols={2}>
  <Card title="Customer handoff" icon="user-shield" href="/evidence/customer-handoff">
    The cover-letter and access pattern for handing a pack to an auditor.
  </Card>

  <Card title="Compliance patterns" icon="list-check" href="/compliance/overview">
    End-to-end workflows that show customization in context.
  </Card>
</CardGroup>