Regulation pillar

Regulation

Regulation is the control pillar: find, qualify, sanction, automate schedules, and collect periodic filings.

Plan: Professional and above (infractions, sanctions, regulatory_rules, reporting). GRC (Enterprise / self-regulator) complements internal compliance — see GRC — and does not replace this pillar when you need operational powers or discipline.

What this pillar covers

Capability	Where it lives	Notes
Infractions / findings	Admin → Regulation; Collector; sometimes Public	Types + PV workflows
Sanctions	Catalogue + applied measures	From infraction, complaint, or direct path
Business rules	Versioned rules engine	Schedules, chains, thresholds
Regulatory reports	Admin → Reports; Entity	Forms (same builder as Collect)
Complaints link	Licences menu (complaints)	Often upstream of a finding

Typical business chain

Report / inspection / complaint
        ↓
   Infraction (PV)
        ↓
   Sanction (catalogue)
        ↓
   Execution follow-up

In parallel: report campaigns (periodicity) → Entity submission → admin review → Analytics data.

Infractions

Purpose: formalize that a gap was observed (field, file, public report).

In admin: infraction types, workflows (draft → validation → execution as configured), instruction queue.

Possible sources: admin agent, Collector, public portal (if open), follow-up from a complaint.

Sanctions

Purpose: apply a measure consistent with your catalogue (warning, fine, suspension, internal corrective measure…).

Regulator: public power.
Self-regulator: network discipline / internal measures — same engine, different legal reading.

A sanction can attach to an infraction, a complaint, or be entered directly per rights.

Business rules

Purpose: avoid handling everything by hand: versioned rules for schedules, thresholds, automatic or semi-automatic chains.

Regulatory reports

Purpose: require structured declarations (monthly, quarterly, ad hoc).

1. Admin creates a type + form (shared form builder).
2. Campaign / deadline opens.
3. Entity (or collect) submits.
4. Admin review; data available for oversight.

This is not GRC: here you mean operational / regulatory reporting, not the ISO risk-audit cycle (both can coexist for a self-regulator).

Applications involved

Interface	Role
Admin	Catalogues, PV instruction, sanctions, rules, report review
Entity	Submit reports, answer follow-ups, see impacts on licences / obligations
Public	Report / complaint per config
Collector	Field findings per bootstrap

REGULATOR vs SELF_REGULATOR

Mode	Regulation reading
REGULATOR	Control of external operators, PVs, public sanctions
SELF_REGULATOR	Internal network control, corrective measures, member reporting

Limits

• Not on Essential (except complaints alone).
• GRC ≠ this pillar: Enterprise / self-regulator for risks-audits-frameworks.
• Rules automation is real power — but must be configured.

Next

• Modules and interfaces
• Authorizations — upstream licences / obligations
• Intelligence — use control data
• GRC and internal compliance
• Plans