Document Generation

Audience: organisation administrators and platform operators. This page covers turning document generation on, the licence decision it asks you to make, and how to turn it off again — everywhere at once if you need to. For what the feature does day to day, see the user guide.

The feature ships disabled and stays disabled until an administrator enables it for a specific organisation. That is deliberate: enabling it is a licensing decision, not a preference.

The licence position

The Secure Controls Framework is published under CC BY-ND 4.0 — attribution required, no derivatives. The “ND” is the whole reason this page exists.

Document generation produces two materially different kinds of output, and collapsing them into one switch would give away a position for no benefit.

The two switches

Switch	Gates	The argument
Enable document generation	The five data-driven documents — Statement of Applicability, Control Status Report, Risk Treatment Plan, Evidence Schedule, Maturity Assessment Report	These list SCF identifiers and control names beside your own implementation status. Nothing is reworded. This is arguably a compilation of factual identifiers rather than a derivative work — the position that keeps a free Council licence intact.
Enable AI-augmented generation	Domain Policies, Procedures and Standards	A language model reads SCF control descriptions and assessment objectives and writes new prose from them. That is unambiguously derivative work. It gets its own switch, its own acknowledgement and its own audit trail.

The second switch cannot be turned on without the first. An organisation that only wants a Statement of Applicability never has to acknowledge a derivative-work position that does not describe what it is doing.

This is a position, not legal advice

The reasoning above is the platform’s design rationale. Whether it holds for your organisation, your SCF licence and your jurisdiction is a question for your own counsel. The switches exist so that you can act on your answer rather than the platform’s.

The acknowledgement

Enabling the feature requires an explicit licence acknowledgement in the same action. The platform records:

• who acknowledged it (user and email);
• when;
• the IP address it came from;
• the version of the acknowledgement wording they accepted.

That last one matters: if the wording changes materially, its version is bumped, and an organisation that accepted the earlier text is not silently treated as having accepted the new one.

Disabling the feature does not clear the acknowledgement. Turning generation off does not un-derive documents already produced, and the record of who accepted that position is the part most worth keeping. Every settings change also writes an audit-log entry carrying both the before and after state, so a single row answers which switch moved.

Enabling it

Settings → Document Generation, as an organisation administrator.

1. Read the licence notice.
2. Tick the acknowledgement.
3. Enable Document generation.
4. Optionally enable AI-augmented generation as a second, separate decision.

The UI enforces this order, but the UI is the weakest of four layers and is treated as courtesy rather than control. The same rules are enforced at the API boundary, in the background worker before any work begins, and by a database constraint that makes an enabled-but-unacknowledged row physically unstorable. A direct PUT from a script bypasses the interface and none of the other three.

The platform kill switch

Setting DOC_GEN_DISABLED=1 in the backend environment refuses every generation request for every organisation, regardless of their settings.

It does not unpick anyone’s configuration, delete documents already generated, or clear any acknowledgement. It is the operator’s lever for a licensing question that needs answering before more derivative work is produced — not a feature toggle. Unset it and every organisation returns to its own settings.

Configuration

All optional. None of these switch the feature on; that is the per-organisation setting above.

Variable	Effect
ANTHROPIC_API_KEY	Reused from the AI assessment configuration. There is no separate key for document generation.
DOC_GEN_AI_MOCK	Set to 1 to return a clearly-marked sample instead of calling the API.
SCF_AI_MODEL	The model every AI feature calls, including this one. One variable for the whole platform — set it when a model is retired or superseded.
DOC_GEN_AI_MODEL	Pin document generation to a different model from the rest of the platform. Beats SCF_AI_MODEL; leave unset unless you are holding this one feature back.
DOC_GEN_DISABLED	Set to 1 for the platform-wide kill switch above.

No key is required to evaluate the feature. With ANTHROPIC_API_KEY unset, or with DOC_GEN_AI_MOCK=1, the AI-augmented generators return a clearly-marked sample rather than failing. The whole feature is walkable end to end — generate, edit, merge, review, export — without spending anything. The five data-driven documents never call a language model at all, key or no key.

Cost, and how it is bounded

Only the AI-augmented generators cost anything, and three things keep that bounded:

• Fingerprinting. Before generating, the platform hashes the control data in scope, the template, the prompt and the catalogue version. Unchanged inputs skip the run entirely — no call, no charge. A scheduled weekly regeneration across an unchanged estate costs nothing.
• Domain scoping. Policies, procedures and standards are generated per SCF domain and only for the domains a user selects. There is no “generate everything” that quietly fans out across the whole catalogue.
• One run at a time. A per-organisation lock means concurrent requests queue rather than multiplying.

A user can override the fingerprint skip with Force regeneration. That is intentional — it is how you pick up a changed prompt — but it is the one path that will regenerate an unchanged document.

Operational notes

Background work. Generation runs on the standard Celery worker queue, alongside evidence assessment and the other background jobs. No additional worker or queue configuration is required for a standard deployment.

Migrations. The feature adds five tables. They are created by the normal alembic upgrade head that runs during deployment; no manual step is needed. See Deployment.

PDF export. PDF rendering requires the system libraries already present in the backend container image. If PDF export returns a 503 in a non-container deployment, that dependency is missing — Markdown and HTML export are unaffected.

Tenancy. Documents belong to the organisation that generated them. Every query is scoped to the caller’s own membership rather than to the organisation identifier in the URL, so a document identifier from another tenant returns “not found” rather than a permission error.

Related

• Generated Documents (user guide) — using the feature
• Configuration — the full environment reference
• Platform Catalog Upgrade — what a catalogue move does to existing documents