This is an old revision of the document!

Editorial guide

version: 8.2 updated: 8 April 2026 status: published

This guide covers the principles, process, and standards that apply to every topic page. Read it before drafting. For markup syntax and formatting examples, see the Wiki markup reference.

Wiki principles

These principles apply to every topic page. They are the shared standards the whole wiki is built on.

Table 1. Wiki principles and what they mean in practice.

Principle	What it means in practice
Transparency	All contributions, including AI-assisted work, must be documented and attributed.
Credibility	Every factual claim requires a source. Prefer primary sources: original papers, official documents, standards.
Triangulation	Every topic is developed from three perspectives — actors, technology, institutions — because no single discipline captures smart grid transitions on its own.
Scope	State clearly whether a definition or claim is global, regional, or discipline-specific. Where it originates matters.
Accessibility	Write for all three audiences. Define technical terms on first use.
Knowledge integration	Build on ISGAN publications as a baseline. Connect to broader literature where it expands the ISGAN framing.
Critical reflexivity	Where emerging literature challenges the current ISGAN framing, acknowledge it. The wiki's value depends on intellectual honesty.
Feasible effort	Quality matters more than completeness at first publication. A well-grounded page that grows over time is better than one delayed indefinitely.
Referencing	Use APA 7th edition. Include a DOI or stable URL where available. Verify all sources before submitting.
Copyright	For any image, confirm the licence permits use and include attribution and a source link.

The three perspectives

Smart grid transitions cannot be fully understood from any one disciplinary perspective. Engineering analysis reveals what is technically feasible. Institutional analysis explains what rules and incentives make certain options viable. The study of actors and practices shows who acts and how. Each approach illuminates something the others miss, and each carries specific blind spots.

Triangulation is a method from the social sciences for understanding real-world phenomena by combining multiple theoretical perspectives and methods. The aim is to compensate for the limitations of any single method and to strengthen the credibility of findings through convergence across different approaches.

Using multiple perspectives in combination makes it possible to understand phenomena in a more differentiated way: to identify priorities based on a fuller picture, to spot where different framings are compatible and where they conflict, and to develop options that are robust across more than one frame of analysis.

A finding that holds across independent perspectives is more credible than one that depends on a single method or theory.

Every topic is explored from three perspectives. These are not separate sections to fill in independently; they are lenses that together give a fuller picture of how a smart grid concept operates in the real world. Where the perspectives interact, or where one uniquely exposes something the others miss, this should be made explicit in the text.

Actors and stakeholders

This perspective addresses the activities and practices of the multiple groups whose actions shape smart grid transitions.

Market actors — energy suppliers, producers, aggregators, storage providers, and consumers at the grid edge — participate in markets for energy and capacity. Transmission and distribution grid operators, balancing parties, and the institutions that regulate them carry mandates to operate and invest in specific parts of the electricity system. National and local policy makers, regulatory bodies, civil society organisations, and citizens shape framework conditions through law-making and political decisions. Technology providers and research organisations are part of the innovation ecosystem and play an active role in transitions even when they are not direct market participants.

Key disciplines: Microeconomics, behavioural economics, organisational studies, business administration.

Technologies and infrastructure

This perspective addresses the technical components, systems, and infrastructures that make up the electricity system, and the ways they can be configured to fulfil system functions. It covers generation, transmission, distribution, and storage as functionalities of a cyber-physical system, including both physical infrastructure and the digital layer of data exchange, control systems, and communication protocols.

The technology perspective extends beyond hardware. Interoperability standards, data exchange interfaces, metering systems, and control architectures are all within scope, and often where the most consequential transitions are taking place.

Key disciplines: Electrical engineering, informatics, systems engineering.

Institutional structures

This perspective addresses the rules, regulations, norms, and cognitive frameworks that govern the electricity system. Markets for power and energy, grid codes, regulatory frameworks for grid operation and balancing, and rules for energy communities and aggregation are all institutional arrangements that define what is possible and what is incentivised.

Understanding how open or resistant an institutional structure is to change is often as important as understanding the technical options available.

Key disciplines: Institutional and evolutionary economics, political science, sociology.

Tone and voice

Topics should read as though written by a knowledgeable colleague explaining something clearly. The goal is directness and precision, not performed expertise. Write for the reader's understanding, not for the author's credibility.

Language rules:

Use plain language. If a technical term is necessary, define it on first use.
Prefer active constructions: “Several countries have introduced regulatory sandboxes” rather than “Regulatory sandboxes have been established.”
Prefer can and could over should when describing possibilities. The wiki describes what institutions do and what options exist. It does not prescribe what countries ought to do.
Avoid hollow evaluative phrases: “a fundamental shift”, “a critical enabler”, “plays an increasingly important role.” State what changed and why it matters.
Avoid generic prose markers: “It is important to note that”, “This section explores”, “Moreover”, “Furthermore.”
Avoid unnecessary introductions: “In an era of increasing complexity”, “Given the rapidly evolving landscape.”
Vary sentence length for readability and flow; avoid overly long sentences.

Headings: All section headings use sentence case. Write “Why this matters”, not “Why This Matters”.

Roles

Wiki development is a co-creative process. Every topic has a small team.

Table 2. Contributor roles and responsibilities.

Role	Responsibilities
Lead author	Oversees the topic from first draft to publication. Organises co-author collaboration, manages review, addresses comments, and takes responsibility for accuracy.
Contributor	Contributes original input based on their expertise, primarily during content creation. May also support later revisions.
Reviewer	Provides at least one round of structured feedback. Critical comments must be addressed before the topic advances.
WG7 Task Lead	Coordinates the overall editorial process, the Quality Review Panel, and publication logistics.
Communications Working Group	Handles upload, promotional activities, and coordinates publication logistics.
Quality Review Panel	Expert reviewers from at least three countries, with at least one outside the EU. Provides structured feedback during Stage 2.
Inter-working group meeting	Endorses the shared definition. Endorsement is required before a topic is published and again if the shared definition is subsequently changed.

Becoming a lead author

Lead authors are the core of the wiki and every topic needs one. Lead authors takes responsibility for a topic from first draft to publication: organising input from co-authors, coordinating the review process, addressing comments, and keeping the topic current after it is published.

What is expected:

Commitment to oversee the topic from the first draft to publication, including addressing reviewer comments and coordinating with the contributors
Subject-matter expertise relevant to the topic, ideally covering more than one of the three ISGAN perspectives (actors, technology, institutions)
Willingness to regularly update the topic based on feedback and new evidence.

On diversity: Topic teams work best when lead authors and contributors bring diverse ISGAN perspectives and regions. If you are taking on a topic, consider who else might contribute from a different disciplinary or geographical angle.

To sign up as lead author: Contact the WG7 Task Lead or reach out via the contact page. If a topic already has a lead author listed on its page, contact them directly to discuss collaboration.

To propose a new topic: See the New topic guide.

Editorial process

The process has three stages and three decision gates. Gate 1 is a lead author self-check before external review begins. Gate 2 is the substantive quality threshold before endorsement.

The inter-working group meeting endorses the shared definition only. All other content — perspectives, case studies, examples, references, distinctions — can be edited after publication without a new endorsement. A new inter-WG meeting is required only if the topic definition or specific shared definitions are altered.

Table 3. Editorial process stages, gates, indicative durations, and status values.

Stage / Gate	What happens	Duration	Status
Stage 1: Content creation	The lead author collects input from co-authors and produces a first draft using the topic template.	2–6 weeks	`draft`
Gate 1	The lead author checks that the draft is ready for external review: the template is complete, every factual claim has a source, and all contributors are attributed.	1 day	—
Stage 2: Review	Expert reviewers provide written feedback. The text is revised for accuracy, readability, and style. Critical comments must be addressed before the topic can advance.	4–8 weeks	`in-review`
Gate 2	Review is complete. All critical comments have been resolved, the shared definition is stable, and the topic is ready for endorsement.	—	—
Stage 3: Awaiting endorsement	The lead author submits the topic to the inter-WG meeting agenda. Language is reviewed and finalised before submission. The draft may go live on the wiki while endorsement is pending.	Aligned to WG schedule	`under-approval`
Gate 3	The inter-WG meeting reviews and endorses the shared definition.	—	—
Publication	The topic goes live on the wiki. A two-week community review window opens, during which the lead author addresses any substantive concerns raised.	2–3 weeks	`published`

Gate 1 checklist

Completed by the lead author before sharing the draft externally. No external sign-off required.

☐ The topic template is used, including the shared definition, three perspective subsections, and section word limits.
☐ Every factual claim has a source. Geographical scope is stated. Technical terms are defined on first use.
☐ Lead author and all co-authors are attributed in the metadata block.

Milestone 1: Draft is ready for external review.

Gate 2 checklist

Confirmed by the lead author and WG7 Task Lead before the topic moves to Stage 3. Any comment marked critical must be addressed before the topic proceeds. If the lead author disagrees with a critical comment, the reasoning must be documented and the reviewer informed.

☐ At least three expert reviewers from at least three different countries have provided written feedback, with at least one reviewer from outside the EU.
☐ All critical comments have been addressed. Any disputed critical comment has been documented in writing and the reviewer informed.
☐ All sources have been verified: every cited document exists at the given URL, titles and authors are correct, and the cited content matches the claim in the text. References are complete and formatted in APA 7th edition.
☐ The distinctions and overlaps section addresses confusions that readers of this topic actually encounter.
☐ The shared definition is stable and ready for inter-WG endorsement.

Milestone 2: Topic is ready for endorsement.

Gate 3 checklist

Confirmed by the lead author before submitting to the inter-WG meeting.

☐ The shared definition has not changed since Gate 2. If it has changed, the topic returns to Stage 1.
☐ No critical issues remain unresolved from Gate 2.
☐ Language has been reviewed and finalised by the lead author.
☐ Topic has been submitted to the inter-WG meeting agenda.

Milestone 3: Topic is ready for publication.

Sensitivity rating

Topics may be assigned sensitivity ratings, however how they should function is still to be decided. At the moment no sensitivity ratings are assigned.

Versioning

Every topic page carries a version number. The version and status move together at defined triggers.

Table 4. Version change triggers and their process effects.

Event	Version	Status	Process
First publication	→ 1.0	→ `published`	The topic completes Stage 4 and goes live.
Minor revision	e.g. 1.0 → 1.1	Unchanged	No process steps required. Can be made at any status.
Major revision	e.g. 1.0 → 2.0	→ `draft`	The topic returns to Stage 1. A new inter-WG endorsement is required before republication.

Major version (e.g., 1.0 to 2.0): A change to the shared definition or core framing of the page. Requires returning to Stage 1 and a new inter-WG endorsement.
Minor version (e.g., 1.0 to 1.1): An editorial improvement, updated case, added reference, or corrected phrasing. Can be made at any status without restarting the process.

Once a shared definition is endorsed, only the definition is locked. The rest of the page remains open to improvement as minor revisions at any time. If contributors believe the definition needs changing, that triggers a major revision and a new endorsement cycle.

Start at version 1.0 on first publication. Update the version number and the updated date in the page metadata on every change. Use the optional topic notes section to record what changed between versions.

Topic page structure

Every topic page follows the same structure. Sections must appear in this order.

Table 5. Required sections for every topic page, in order.

#	Section	Purpose
1	Category badge	Identifies which of the five categories this topic belongs to.
2	Title	The topic name.
3	Metadata block	Records lead authors, contributors, reviewers, version, date, sensitivity, status, and AI use. Drives the status display and author attribution on the start page.
4	Intro panel	One paragraph defining the topic and situating it in smart grid transitions. Every sentence must be specific to this topic.
4b	Insight block	A single plain-text sentence, 120–160 characters, no links or markup. Not visible on the topic page; feeds the topic card on the start page.
5	Why this matters	One to two paragraphs and one callout box explaining why the topic matters for smart grid transitions.
6	Shared definitions	The working definition, with an optional table for multi-dimensional concepts.
7	Perspectives	Three subsections (Actors and stakeholders, Technologies and infrastructure, Institutional structures), each with one paragraph and one to three case examples.
8	Distinctions and overlaps	Two to five entries clarifying what this topic is not, and where it borders adjacent concepts.
9	Related topics	Direct links to other topic pages using `[[topics:slug\|Title]]` format. Not tags.
10	References	Full APA 7th edition, auto-generated from inline footnotes.
11	Topic notes	Editorial working notes, gap log, AI attribution, and verification record. Not published on the live wiki.

For markup syntax and code examples for each section, see the Wiki markup reference.

Topic status

Each topic carries a status visible on the start page and on the topic page. The lead author is responsible for keeping it current. Only topics with status published, under-approval, in-review, or draft are counted as active topics.

Table 6. Topic status values, transitions, and gate anchors.

Status	Meaning	Enters when	Exits when
Published	Live and publicly visible.	Stage 4 upload is complete.	A major revision begins, returning the topic to `draft`.
Under approval	Quality review is complete; the topic is awaiting endorsement at an inter-WG meeting.	Gate 2 is passed.	The shared definition is endorsed at an inter-WG meeting.
In review	Under editorial revision and quality panel review. Expert input is especially valuable at this stage.	Gate 1 is passed.	Gate 2 is passed.
Draft	Actively being written or undergoing major revision.	Work begins, or a major version bump is made.	Gate 1 is passed.
Planned	Content exists from an earlier wiki version but has not been updated to the current template and standards.	Old content is confirmed to exist.	Restructuring begins, moving the topic to `draft`.
Backlog	Topic identified; nothing written yet.	The topic is added to the registry.	Work begins, moving the topic to `draft`.

Comment system

Every topic page allows for comments from lead authors, contributors and reviewers within the main body of the text.

How it works:

Select any passage of text on a topic page and a comment button appears. Click it to open a compose panel. Your comment is anchored to the selected passage and visible to other logged-in users via highlight markers in the text. Comments can be replied to, resolved, and closed by the lead author or an admin. The toggle button near the top of each topic page switches comment markers on and off. This does not delete comments but only hides the highlights for a cleaner reading view.

Who can comment: Any logged-in wiki user once editor rights are granted. Comments are not visible to anonymous readers.

Who can resolve comments: The lead author and wiki admins. Resolving a comment marks it as addressed; it remains in the record but is no longer shown as open.

Examples of instances for using comments:

Flag a specific claim that needs a source or stronger evidence
Note a definition that may conflict with another topic
Suggest a phrasing change
Mark a passage for follow-up after a meeting

AI use

AI tools may be used in wiki development when helpful, but their use is not required or expected. Where AI is used, it can help reorganise source material into the template structure, improve sentence flow, reformat references, or convert approved documents into DokuWiki markup.

Three responsibilities remain with people regardless of AI assistance:

Source verification is mandatory and must be done by a person. The lead author is responsible for confirming that every cited source exists and that the content matches the claim in the text.
Editorial responsibility stays with the lead author. Co-authors and reviewers who become aware that AI has substantially altered text must inform the lead author so the attribution record is accurate.
Recording AI use is required. All AI-assisted work is documented in the Topic notes section. These records stay in the document and the Teams folder; they are not published on the live wiki.

AI use record format

[Stage] · [Type] · [Tool (Developer)] · Reviewed by: [Name] [Date]

Example: Content creation · Drafting · Claude Sonnet 4 (Anthropic) · Reviewed by: Firstname Lastname, 17 May 2025.

Version history

Version 8.2 — 8 April 2026 Table prose, TOC cleanup, stage-gate diagram

Rewrote all table cells that previously used clipped, semicolon-separated fragments. The "What happens" column in Table 3 (Editorial process) was the main case: each stage and gate now reads as a sentence describing what happens and who is responsible. The same treatment was applied to the "Process" column in Table 4, the "Purpose" column for the metadata block, insight block, and topic notes entries in Table 5, and the "Enters when" and "Exits when" columns in Table 6. The three perspectives subsections and the three gate checklists were demoted from level-3 headings to bold paragraph leads so they no longer appear in the table of contents. An SVG stage-gate diagram was added above Table 3, showing the full flow from Stage 1 through publication and the return path for major revisions.

Version 8.1 — early April 2026 Details not recorded

Revision notes for this version were not transferred to this record. See the editorial Teams folder for working notes from this period.

Version 7 Details not recorded

Revision notes for this version were not transferred to this record. See the editorial Teams folder for working notes from this period.

Version 6 — March 2026 Comprehensive rewrite; AI use; target audiences; full wiki migration

A comprehensive rewrite that significantly expanded the scope and quality of the guide. The three triangulation perspectives were given a full standalone section with detailed descriptions of what each covers and which disciplines it draws on, replacing the earlier brief list format. A structured target audiences table was introduced, distinguishing the needs and writing implications for ISGAN experts, policy makers, and researchers. An AI use section was added with a structured record format for logging AI-assisted work by stage and type. Sensitivity rating criteria were introduced as a provisional proposal, pending formal agreement within ISGAN. Roles were further clarified, and the stage-gate descriptions were made more specific. The "content only" naming convention from Version 5 was dropped, as markup guidance had by then been fully separated into the wiki markup reference page.

Version 5 — August 2024 Content split; four-stage process; Quality Review Panel introduced

First version filed as "content only," reflecting the decision to separate editorial guidance from markup and technical instructions into distinct documents — the split that produced the wiki markup reference as a companion to this guide. The numbered-rules format was fully replaced by named wiki principles. A formal roles section was introduced, distinguishing high-level wiki-wide roles from topic-level roles (owners, co-authors, reviewers). The editorial process was expanded to four stages, with an explicit Quality Review Panel requiring ExCo delegates from at least five countries. Milestone markers were added at the end of each stage. Klaus Kubeczko, Vitaliy Soloviy, and Max Gasser are named as contributors from this version onward.

Version 4 Rules become named principles; restructuring begins

A substantial restructuring attempt that moved away from the numbered-rules format toward named principles (Transparency, Triangulation, Geography and scope, Copyright, and others). A purpose and target audience preamble was added at the front. Several sections were started but left as placeholders, and the document was incomplete at the time of filing — it represents a transitional draft rather than a stable version. The background section was shortened and rewritten to focus on rationale rather than origin story.

Version 3 Minor edits to technical section

Minor update to Version 2. The main change was the addition of a screenshot showing Teams-based registration to the technical access section. Content structure, rules, and stage-gate process were unchanged.

Version 2 Title and background revision

Renamed from "Editorial Guide for the ISGAN online Wiki" to "ISGAN Smart Grids Transitions Wiki — Editorial Guide." The background section was lightly revised, with the framing shifted from "there is a need" to "there is broad agreement about the need." Otherwise the structure, nine rules, technical access guide, and stage-gate process were unchanged from Version 1.

Version 1 — late 2023 First draft

First complete draft of the editorial guide, produced within WG7 during the initial wiki setup phase. The guide covered nine numbered rules (transparency and attribution, triangulation of perspectives, geographical scope, contentious terms and footnotes, cross-checking with IEEE and IEC glossaries, word limits, referencing in APA 7th edition, copyright for images, and page ownership), a technical access section with step-by-step instructions for logging in, adding pages, and subscribing to changes, and a three-stage process with Gate 1 as a page owner self-check. The three perspectives were present from the start as Institutions, Actors and Stakeholders, and Technology. The guide was a single document combining editorial policy and technical onboarding.