Skip to main content

CODITECT Standard: Project Status Reporting

Standard ID: CODITECT-STANDARD-STATUS-REPORTING Version: 1.0.0 Effective Date: 2026-02-06 Owner: CODITECT Framework Team

1. Purpose​

This standard defines the format, content requirements, and quality criteria for project status reports within the CODITECT framework. It ensures consistent, actionable, and verifiable project reporting across all projects.

2. Scope​

This standard applies to:

  • Customer project status reports (CUST-*)
  • Internal PILOT project reports
  • Phase checkpoint reports
  • Sprint/iteration reviews
  • Executive/board updates
  • Investor reports
  • Incident reports

3. Report Types​

3.1 Report Type Matrix​

TypeFrequencyAudienceTemplate
Initial StatusOnce per projectAll stakeholdersPROJECT-STATUS-REPORT-TEMPLATE.md
Phase CheckpointEnd of each phaseProject team, sponsorsCHECKPOINT-TEMPLATE.md
Sprint ReviewEnd of sprintDevelopment teamSPRINT-REVIEW-TEMPLATE.md
Executive UpdateWeekly/MonthlyLeadershipEXECUTIVE-SUMMARY-TEMPLATE.md
Board UpdateQuarterlyBoard membersBOARD-UPDATE-TEMPLATE.md
Investor ReportMonthly/QuarterlyInvestorsINVESTOR-REPORT-TEMPLATE.md
Incident ReportAs neededAffected partiesINCIDENT-REPORT-TEMPLATE.md
Decision ReportAs neededDecision makersDECISION-REPORT-TEMPLATE.md

4. Required Sections​

4.1 Mandatory Sections (All Reports)​

Every project status report MUST include:

SectionPurposeFormat
Report MetadataIdentificationYAML frontmatter
Executive SummaryQuick overview3-5 bullet points
Overall StatusHealth indicatorDashboard table
Track ProgressPer-track statusProgress table with %
Key AccomplishmentsWhat was doneDated list
Critical Path ItemsWhat's blockingRisk-ranked table
Decisions MadeWhat was decidedDecision log format
Next ActionsWhat's nextPrioritized list with owners

4.2 Optional Sections (As Needed)​

SectionWhen to Include
Risk RegisterHigh-risk projects
Budget StatusBudget-tracked projects
Resource AllocationMulti-team projects
Stakeholder UpdatesExternal stakeholders
Technical DebtDevelopment projects
Quality MetricsQuality-focused reviews

5. Status Indicators​

5.1 Overall Project Health​

StatusIndicatorCriteria
GreenOn Track≥80% tasks on schedule, no critical blockers
YellowAt Risk60-79% on schedule OR 1-2 critical blockers
RedOff Track<60% on schedule OR ≥3 critical blockers
CompleteDone100% tasks complete, acceptance verified

5.2 Track Progress​

ProgressIndicatorMeaning
0%🔴 Not StartedNo tasks begun
1-39%🟡 In ProgressWork underway
40-79%🟡 Significant ProgressMajor milestones achieved
80-99%🟢 Near CompleteFinal tasks remaining
100%✅ CompleteAll tasks verified

5.3 Critical Path Classification​

PriorityLabelResponse Time
P0Critical BlockerImmediate (same day)
P1High Priority24-48 hours
P2Medium Priority1 week
P3Low PriorityNext sprint

6. Progress Calculation Methodology​

6.1 Task-Based Progress​

Track Progress = (Completed Tasks / Total Tasks) × 100

6.2 Weighted Progress (Complex Projects)​

Weighted Progress = Σ(Task Weight × Completion %) / Σ(Task Weights)

6.3 Phase Progress​

PhaseWeight
Requirements15%
Architecture15%
Development40%
Testing20%
Deployment10%

7. Risk Assessment Format​

7.1 Risk Register Structure​

FieldDescriptionRequired
Risk IDUnique identifierYes
DescriptionWhat might happenYes
ProbabilityLow/Medium/HighYes
ImpactLow/Medium/HighYes
Risk ScoreP × I (1-9)Yes
MitigationPlanned actionsYes
OwnerResponsible personYes
StatusOpen/Mitigating/ClosedYes

7.2 Risk Scoring Matrix​

Impact ↓ / Probability →Low (1)Medium (2)High (3)
High (3)3 - Yellow6 - Red9 - Red
Medium (2)2 - Green4 - Yellow6 - Red
Low (1)1 - Green2 - Green3 - Yellow

8. Decision Log Format​

8.1 Required Decision Fields​

FieldDescription
Decision IDUnique identifier (DEC-YYYY-MM-DD-NNN)
DateWhen decided
DecisionWhat was decided
RationaleWhy this choice
AlternativesOptions considered
ImpactWhat this affects
OwnerWho made decision
StatusProposed/Approved/Implemented

8.2 Decision Categories​

CategoryCodeExamples
ArchitectureARCHTechnology choices, patterns
ProcessPROCMethodology, workflow
ResourceRSRCBudget, staffing
ScopeSCOPFeature inclusion/exclusion
TimelineTIMESchedule changes
RiskRISKRisk acceptance/mitigation

9. Report Lifecycle​

9.1 Creation and Updates​

┌─────────────────────────────────────────────────────────────┐
│                    REPORT LIFECYCLE                          │
│                                                              │
│  CREATE          UPDATE           ARCHIVE                    │
│     │               │                │                       │
│     ▼               ▼                ▼                       │
│  ┌──────┐      ┌──────────┐     ┌──────────┐                │
│  │ v1.0 │ ──▶  │ v1.1...  │ ──▶ │ FINAL    │                │
│  └──────┘      └──────────┘     └──────────┘                │
│     │               │                │                       │
│     └───────────────┼────────────────┘                       │
│                     ▼                                        │
│               SINGLE FILE                                    │
│         (append new sections)                                │
└─────────────────────────────────────────────────────────────┘

9.2 Update Rules​

  1. Single Source of Truth: One report file per project per period
  2. Append-Only: New updates appended to existing report
  3. Version Header: Each update gets dated section header
  4. Archive Policy: Reports archived after project completion

10. Quality Criteria​

10.1 Minimum Quality Score: 90/100​

CriterionWeightScoring
Completeness25%All required sections present
Accuracy25%Data matches TRACK files
Timeliness15%Within reporting window
Actionability20%Clear next steps with owners
Clarity15%Readable by target audience

10.2 Validation Checklist​

Before publishing, verify:

  • All required sections present
  • Progress percentages match TRACK files
  • Critical path items have owners and dates
  • Decisions have rationale documented
  • Risk items have mitigation plans
  • Next actions are specific and assigned
  • Report passes spell/grammar check
  • LLM author attribution included

11. Templates​

11.1 Available Templates​

TemplateLocationPurpose
PROJECT-STATUS-REPORT-TEMPLATE.mdcoditect-core-standards/templates/Full status report
CHECKPOINT-TEMPLATE.mdcoditect-core-standards/templates/Phase checkpoint
RISK-REGISTER-TEMPLATE.mdcoditect-core-standards/templates/Risk tracking
DECISION-LOG-TEMPLATE.mdcoditect-core-standards/templates/Decision documentation

11.2 Template Usage​

# Generate status report
/status-report --type initial --project CUST-avivatec-fpa

# Generate checkpoint
/status-report --type checkpoint --phase 2

# Generate risk register
/status-report --type risk --project CUST-avivatec-fpa

12. Session Log Attribution​

Every report MUST include LLM attribution:

**Author:** Claude (Opus 4.5)
**Generated:** 2026-02-06T00:00:00Z
StandardRelationship
CODITECT-STANDARD-AUTOMATION.mdTask ID requirements
CODITECT-STANDARD-TRACK-NOMENCLATURE.mdTrack naming
CODITECT-STANDARD-MEETING-ANALYSIS.mdDecision extraction

14. Governance​

RoleResponsibility
Project LeadReport accuracy, timeliness
Senior ArchitectTechnical content review
Framework TeamStandard maintenance

15. Revision History​

VersionDateAuthorChanges
1.0.02026-02-06Claude (Opus 4.5)Initial standard

Standard Owner: CODITECT Framework Team Review Cycle: Quarterly Next Review: 2026-05-06