Skip to main content

​
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.
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.

​
What can be customised

​
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).
1

Compose the template

Templates are a tarball with the following structure:
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.
2

Validate locally

The preview subcommand renders against a real release without uploading the template — useful for iterating on the design.
3

Upload

Project Settings → Evidence → Templates → Upload. Or:
Uploaded templates are versioned; rolling back is a one-click revert.
4

Apply to a generation

On the Generate Evidence Pack modal, pick the uploaded template from the dropdown. From CLI:

​
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:

​
Next steps

Customer handoff

The cover-letter and access pattern for handing a pack to an auditor.

Compliance patterns

End-to-end workflows that show customization in context.