Priority Framework

Use this framework to classify gaps by deployment criticality. The priority level determines when the gap must be closed, not how hard it is to fix.

Priority Levels

P0 — Required for Initial Deployment

Blockers that prevent the service from running in any environment.

Examples:

• No Dockerfile or container build capability
• No deployment pipeline (CI builds but never deploys)
• No infrastructure provisioned (no App Service, no database, no registry)
• No telemetry SDK (cannot observe the service in production)
• No real authentication (placeholder tokens only)
• No coverage thresholds (no quality gate on changes)

Test: "Can the service be deployed to a dev environment and accessed by a real user?" If no, it's P0.

P1 — Required for Production Promotion

Gates that must pass before the service moves from local development through pre-production and into a production environment.

Examples:

• No secrets management (plaintext connection strings)
• No network security (public endpoints for internal services)
• No production database (using SQLite or in-memory storage)
• No CORS hardening (wildcard origins)
• No manual approval gates on deployment
• No change management integration (ServiceNow, etc.)

Test: "Would a security review or change advisory board block this from going to production?" If yes, it's P1.

P2 — Required for Operational Maturity

Improvements needed for sustainable production operation.

Examples:

• No structured logging (default stdout only)
• No custom metrics or dashboards
• No runbooks (startup, recovery, incident)
• No release communication (Teams/Slack notifications)
• No handover documentation
• No load testing baseline

Test: "Can the on-call team operate this service confidently at 2am?" If not, it's P2.

P3 — Nice to Have / Cross-Pollination

Improvements that exceed the target standard or benefit the broader portfolio.

Examples:

• Practices from the assessed codebase that the reference portfolio should adopt
• Tooling that exceeds the target (stricter linting, more CI gates)
• Documentation practices that set a new benchmark
• Patterns that could be templated for other repos

Test: "Would adopting this improve the team's overall engineering quality?" If yes, it's P3.

Effort Estimates

Attach an effort estimate to each gap to enable planning:

Effort	Definition
Trivial	< 1 hour. Config change, file creation, flag toggle.
Small	Half day to 1 day. Single file, clear pattern, no dependencies.
Medium	1–3 days. Multiple files, some design decisions, possible dependencies.
Large	3+ days. Cross-cutting change, new infrastructure, external approvals needed.

Presentation Rule

Present gaps in a table per priority level:

#	Gap	Effort	Notes
1	Description of the gap	Small/Medium/Large	Context, dependencies, recommendations

Order within each priority level by effort (smallest first) to enable quick wins.