Configurable auto-generated ref_id templates per object type — for multi-team deployments

[rajeshkhanikar]

Context

I'm setting up a CISO Assistant Community Edition deployment for an asset-owner organisation with ~40 renewable-energy plants (wind, solar, BESS, electrolyser). The deployment is used concurrently by:

• Plant-level O&M teams (Wind, Solar, Electrolyser) — different technology expertise per sub-system
• Project managers — one per project, juggling lender DD and internal cyber programmes
• Procurement / supplier-assurance reviewers
• Corporate cybersecurity team
• Legal / brand-protection team
  That's easily 30+ users concurrently creating Findings, AppliedControls, Incidents, Assets, RiskScenarios, Solutions, Contracts, Threats across multiple projects.

The problem with free-text ref_id

ref_id is currently a free-text input on every governance object (Finding, AppliedControl, Incident, Asset, Solution, Contract, Threat, RiskScenario, Perimeter…). No format enforcement, no auto-generation, no per-tenant template.

That works in a single-curator lab. At organisational scale, different users adopt incompatible ad-hoc conventions:

User	Created Finding ref_id
Cyber Engineer A	F001
Cyber Engineer B	Finding-2026-001
Plant Manager C	Amigo_Wind_F1
Auditor D	(leaves it blank)
Compliance E	2026.01.001

Three months later, when the lender audit asks "show me all open Findings", the list is unfilterable, unsortable by ID, and visibly inconsistent. The CISO loses time arguing with auditors about ID hygiene instead of demonstrating cyber posture.

Why this matters beyond cosmetics

ref_id is not just a display string — it appears in:

• Exported PDFs / XLSX from FindingsAssessments (intended for external auditors and lenders)
• Cross-cutting list views (/findings, /applied-controls, /incidents, /risk-scenarios)
• Sankey / sunburst aggregate visuals (the labels)
• The CISO's monthly metric pack to the board
  Inconsistent IDs make the artefact look unprofessional in the very forums where it's supposed to demonstrate governance maturity.

Precedent — EBIOS RM operational scenarios already auto-generate IDs

Issue #3338 confirms that EBIOS RM operational scenarios do auto-generate IDs (AP.01, AP.02, …). The pattern exists in the codebase — it just hasn't been:

1. Extended to other object types (Finding, AppliedControl, Incident, Asset, Solution, Contract, Threat, RiskScenario, Perimeter)
2. Made configurable per tenant / per organisation
3. Made robust (the linked issue reports duplicate AP.01 IDs)
   This discussion is essentially: take the EBIOS auto-id pattern, make it general, make it configurable, make it robust.

Proposed functionality

A per-tenant ref_id template configuration, settable via the existing /api/settings/general/ namespace (or a new /api/settings/ref-id-templates/ namespace if cleaner) — one template per object type. Variables expanded at item-creation time:

Variable	Meaning
{YYYY}	Current year
{MM}	Current month
{NNN}	Zero-padded 3-digit sequence number, per-template, atomically incremented
{NN}	Two-digit sequence number
{project_code}	The Perimeter's ref_id (when the object is scoped to a Perimeter)
{folder_name}	The folder name slug
{user}	The creating user's identifier

Example tenant configuration

ref_id_templates:
  finding:              "FND-{YYYY}-{NNN}"
  finding_assessment:   "FA-{YYYY}-{NNN}"
  applied_control:      "AC-{NNN}"
  incident:             "INC-{YYYY}-{NNN}"
  threat:               "TS-{NNN}"
  asset:                "{project_code}-AST-{NNN}"     # auto-prefixed when scoped to a Perimeter
  risk_scenario:        "RS-{NNN}"
  solution:             "SOL-{NNN}"
  contract:             "CTR-{project_code}-{NNN}"
  entity:               "ENT-{NNN}"

Example result, three users creating items concurrently

User	Object type	Auto-generated ref_id
Cyber Engineer A	Finding	FND-2026-001
Plant Manager B	Finding (in Amigo perimeter)	FND-2026-002
Cyber Engineer A	AppliedControl	AC-017
Auditor C	Finding	FND-2026-003
Plant Manager B	Asset (under Amigo Wind WP0029)	WP0029-AST-008
Procurement D	Solution	SOL-013

The user creating the item can still override the auto-generated ref_id if needed (e.g. carrying over an ID from a legacy system). This preserves current free-text behaviour as a fallback.

Behaviour around imports / migration

• Data Import Wizard / library load: if the import file provides a ref_id, that one is used. If absent, the template generates one. Backwards-compatible.
• Sequence counter: must be atomic at the API layer (per-tenant lock) to avoid the duplicate AP.01 issue reported in EBIOS RM : impossibilité de changer l'ID d'un scénario opérationnel  #3338.
• Existing items: keep their current ref_ids. The template only applies to new creations.
• Visibility in create form: the auto-generated ref_id shows in the form, editable before save.

Discussion points

1. Per-folder / per-perimeter templates? Some orgs want {project_code} in the prefix (our case); others want a single org-wide sequence. The template syntax above supports both — the variable is only expanded if present.
2. Year roll-over for {NNN}? Year-bound sequences (INC-{YYYY}-{NNN}) reset to 001 on 1 January. Non-year-bound (AC-{NNN}) keep counting forever. The presence of {YYYY} in the template signals the reset behaviour implicitly. Alternative: explicit {NNN_year_reset} and {NNN_global} variables.
3. Multi-tenancy: if intuitem supports multi-tenant deployments (PRO/Enterprise), templates should be per-tenant.
4. Bulk operations: a bulk-create endpoint should reserve sequence numbers as a range (not one-call-at-a-time) for performance.

Why this is feature-request territory (not workaround territory)

The workarounds available today are all unsatisfying:

• Naming-convention policy + manual review gate — relies on human discipline and reviewer bandwidth; doesn't scale beyond ~10 users
• API-side helper script ("call this to get the next ID before creating an item") — introduces a separate tool that users must remember to use before opening CISO Assistant
• Frontend fork — ties the org to a specific CISO Assistant version, locks them out of clean upstream upgrades
  Putting it natively in the tool, with the EBIOS RM auto-id pattern already proving the concept works, feels like the right shape.

---

Happy to help with implementation if it lands on the roadmap. Would be glad to test against the 30+ user / 40-plant deployment described above.