Skip to main content

Authoring and publishing a program

This page is for publishers: the consultancy, law firm or certification body that produces a compliance program other companies install. If you are the company installing one, read Installing a program instead.

Program authoring is off by default. It appears only in an instance where it has been switched on, because most instances belong to companies that consume programs and have no reason to produce them.

What you are building​

A program travels as a single signed file. It carries four things:

  • the manifest, which is the index and the commercial answer sheet (who it covers, how much of each person's time it costs, what must already be in place, what it deliberately does not cover)
  • the role model, your own vocabulary of capabilities, target levels and the assessment scale
  • the bodies, meaning each policy, training and scenario assessment
  • the assignment rules, expressed against your roles rather than against any customer's org chart

The editor holds exactly those four things, and export reassembles them into the file. There is no separate authoring format that has to be kept in sync with what ships.

Starting a program​

New program creates a working draft that already validates. The skeleton is structure only: one placeholder document resting on good practice, a five-point assessment scale, and a first changelog entry. Every claim in it is yours to write.

Import a program loads an existing .bcprogram or .bcpayload as an editable draft. Use it to pick up a program you authored elsewhere, or to continue from a release you have already shipped. A signed file has its integrity checked before anything is stored, so an altered file is refused rather than silently absorbed.

Importing over a program you already have a draft for is destructive and asks first. It would otherwise replace work in progress on a later version with no warning.

The validation panel​

The panel at the top of the editor runs the same checks a customer's instance runs when the file is imported. Nothing else in the editor matters as much: if it is green, the program installs; if it is not, it will be refused, and the message you see here is the message they would see.

Common things it asks for:

  • A legal basis on every artefact, with the kind of obligation and the date you read it. An artefact resting on good practice rather than law says so explicitly. An empty basis is treated as an omission, never as an implicit none.
  • A changelog entry for the version you are on, so the reason a thing changed exists independently of the diff.
  • A body for every artefact the manifest declares, since a file that references content it does not carry installs a hollow program.
  • Grades that the rubrics actually name, because a reviewer cannot grade against a level the role model does not define.

Writing a scenario assessment​

A scenario has two halves and the editor keeps them visibly apart.

What the person sees is the situation and the questions to answer. What only the reviewer sees is the hidden risks, the expected actions and the per-level descriptors. Those land in a place that only your customer's quality function can read.

Keep the second half out of the first. A grading key that reaches the learner turns a competence assessment into a reading comprehension exercise, and nothing about the result looks wrong, which is what makes the mistake expensive.

Two things worth deciding deliberately:

  • The pass rule is a floor on every criterion, not an average. Decide which criteria cannot be traded away.
  • Write descriptors somebody who was not in the room can apply. "Handles it well" is not a descriptor. "Holds the affected batch and states the condition for release" is.

Grading is always done by a named person. There is no automated grader, and one cannot be requested.

Deciding the version​

Pick the level by impact on the company deploying the program, never by how much you edited. A small legal correction that obliges every supervisor to re-read a policy is a bigger release than a large rewrite that changes nothing anybody must act on.

Write the changelog entry before the content edit. An entry written afterwards describes the diff; an entry written first records why, which is what an auditor and your next release both need. Record a loosening as carefully as a tightening, because your customers need to know their exposure dropped.

Requires recertification is an explicit decision, and its cost is real. It re-trains an entire workforce. Triggering it too readily is expensive; not triggering it when you should leaves people certified against content that no longer holds.

Cutting a release and signing it​

Cut this version freezes the release. It records the manifest, the role model, the bodies as shipped and a fingerprint of the exact bytes, then downloads an unsigned payload.

Signing happens on your own machine:

node scripts/sign-program.mjs ai-act-1.2.0.bcpayload --key your-private-key.pem

That produces the .bcprogram you send to your customer.

The application never holds your private key, and this is deliberate. A stolen API key spends somebody's quota; a stolen signing key lets an attacker forge programs to every customer you publish to. Keeping the key off the server is worth the extra step.

Generate a key pair once:

node scripts/pack-program.mjs keygen --id your-name-2026-01

The command prints the line a customer adds to their instance so that your signature reads as trusted rather than merely intact. Share the public key with them out of band, not in the same channel as the program file.

What happens at the other end​

Your customer's instance verifies the file and answers two separate questions. Is it intact is enforced without exception. Is this really you depends on whether they have your key on file; if they do not, they can still install, but they have to acknowledge that nothing proves who produced it, and that acknowledgement is recorded.

Installed content lands unapproved. Policies arrive as drafts, training arrives pending review, and somebody inside the customer organisation who did not write it approves it before anyone is assigned. That is not friction to design around. It is the reason a program can be bought at all: accountability stays with the company running it, and their own segregation of duties is what proves it.