Decision Register Builder

Decision Register Builder

Purpose

Build or review a project Decision Register from evidence available in SharePoint. Identify explicit decisions and genuine decision requirements, separate them from discussion/actions, consolidate duplicate references, and prepare structured register entries. Never invent project facts.

Before Starting

1. Determine the project/content scope from the prompt, selected files, current SharePoint location, or clearly related project content.
2. Treat the current document library or selected files as the starting context, not automatically as the complete project scope.
3. Discover relevant structured SharePoint lists on the current project site before concluding that a project register does not exist.
4. In particular, look for an existing Decision Register implemented as a SharePoint list. Common names include Decision Register, Decision Log, Decisions, Project Decisions, and reasonable project-specific equivalents.
5. If a likely Decision Register list exists, inspect its schema and current entries before proposing new decision IDs or concluding that no existing register is available.
6. Prefer current authoritative artifacts.
7. Treat an existing Decision Register as authoritative for existing IDs and current registered state unless newer authoritative evidence supersedes it.
8. Use only content available to the current user.
9. Ask for clarification only when project scope is materially ambiguous. Do not ask merely because the register uses a different but recognizable list name.

Preferred Sources

Steering/project/architecture board minutes, meeting notes, status reports, charter, solution/architecture documents, risk/issue/action registers, existing Decision Register, change-control records, and other project evidence containing approvals, rejections, deferrals, selections, or unresolved choices. Do not assume every source type exists.

Decision Status Model

• Open — a real decision is required but no final choice is approved.
• Proposed — a specific choice is proposed but awaits approval.
• Decided — authoritative evidence records an approved/accepted/selected/rejected/finalized choice.
• Deferred — authoritative evidence explicitly postpones the decision.
• Superseded — a previously decided item was replaced by a newer decision.
• Unknown — a decision item exists but its current state cannot be established reliably.

Do not infer Decided because an option is preferred, recommended, discussed, planned, or assigned for investigation.

What Counts as a Decision

A Decided item requires evidence of an actual choice or authoritative disposition. Strong indicators include approved, agreed, decided, selected, accepted, rejected, confirmed, authorized, adopted, or equivalent explicit language.

An Open/Proposed candidate requires a concrete choice, approval, or unresolved question that materially affects the project.

Examples:

• "The Architecture Board must select the production hosting topology." → Open
• "The team recommends Azure hosting, subject to Architecture Board approval." → Proposed
• "The Architecture Board approved Azure hosting for production." → Decided

What Does Not Count

Do not create a decision entry for ordinary discussion, informational statements, routine actions/tasks, risks/issues by themselves, agenda topics, recommendations needing no approval, assumptions not treated as decisions, or unauthorized opinions.

"The Architecture Board will review the hosting options next Thursday" is not evidence of a Decided item. It may support an existing Open decision.

Register Fields

Capture when supported:

• Decision ID
• Title
• Status
• Decision / Required Decision
• Decision Owner
• Decision Date
• Required By
• Context
• Rationale
• Alternatives
• Impact
• Related Items
• Evidence
• Confidence

Use Not stated when an important output field is unsupported. Never fill gaps with plausible assumptions.

Step 1: Discover and Establish Existing Register State

1.1 Discover structured project lists

Before extracting new decision candidates, inspect the current project site for relevant structured SharePoint lists.

Do not conclude that no Decision Register exists merely because it is absent from the current document library, selected files, or current folder. A project Decision Register is commonly implemented as a SharePoint list rather than as a document.

Search for likely register lists using:

• list title;
• list description, when available;
• recognizable decision-register columns;
• project context.

Common list names include:

• Decision Register
• Decision Log
• Decisions
• Project Decisions
• reasonable project-specific equivalents

A differently named list can still be the Decision Register when its schema clearly represents project decisions.

Useful schema indicators include columns equivalent to:

• Decision ID
• Title
• Status
• Decision / Required Decision
• Decision Owner
• Decision Date
• Required By
• Rationale
• Alternatives
• Impact
• Related Items
• Evidence

Do not require every column to exist.

1.2 Select the authoritative register

When one likely Decision Register is found:

1. Read its existing entries before proposing new entries.
2. Treat it as the authoritative register for existing Decision IDs and registered state.
3. Preserve existing IDs and never renumber them.
4. Match documentary evidence against existing entries before creating candidates.
5. Detect updates, confirmations, deferrals, superseding decisions, and duplicates.
6. Determine the highest numeric ID only when useful for proposing a future ID.

When multiple plausible decision lists are found:

1. Prefer the list clearly associated with the current project.
2. Prefer the list whose schema and contents best match a project Decision Register.
3. Do not silently combine unrelated decision lists.
4. If two or more lists remain materially ambiguous, state the ambiguity and ask the user which register is authoritative before proposing updates.

1.3 Handle inaccessible or missing registers

Distinguish these cases:

• Register found and readable: use it.
• Likely register found but inaccessible: state that it appears to exist but could not be read with the current user's access. Do not say that no register exists.
• No likely register found after site-level list discovery: state that no accessible Decision Register was found on the current project site and use temporary candidate IDs.
• Structured-list discovery is unavailable in the execution environment: explicitly state that the existing register could not be verified. Do not claim that no register exists.

Only after site-level structured-list discovery has been attempted may the skill fall back to NEW-01, NEW-02, etc.

If no accessible register can be established, use temporary candidate IDs NEW-01, NEW-02, etc. unless the user provides an ID convention.

Step 2: Extract Decision Evidence

Identify passages indicating a decision was made; approval/rejection occurred; a decision is required; a proposed choice awaits approval; a decision was deferred; a prior decision was replaced; or owner/deadline/rationale/alternatives/impact changed. Keep evidence tied to its source.

Step 3: Classify Candidates

For every candidate:

1. Verify it is a genuine decision item.
2. Assign the most evidence-supported status.
3. Match it to an existing entry if applicable.
4. Capture only supported fields.
5. Assign confidence:
   • High — explicit decision language and clear authority/context.
   • Medium — decision intent is clear but a material aspect is ambiguous.
   • Low — possible decision, but evidence is insufficient for safe registration.

Never present Low-confidence candidates as confirmed decisions.