Content Flow Model

All content flows through a defined process:

• 1. Input: Humans provide vision, requirements, decisions, architecture
• 2. Validate: Markus validates against schemas and specifications
• 3. Publish: Markus publishes to production
• 4. Review: Team reviews published content
• 5. Iterate: Feedback loop back to Input

Humans are the truth owners. Markus is the publisher. This separation ensures quality and consistency.

Detailed Workflow: New Blueprint Creation

Phase 1: Discovery & Planning

Who: Greg (vision), Kristina (planning), Rafa (feasibility)

Steps:

• 1. Identify project needing blueprint
• 2. Schedule discovery meeting
• 3. Gather inputs:

- Project vision and goals - Key decisions made - Technical architecture - Team structure - Risks and constraints

• 4. Document inputs in structured format
• 5. Approve scope with team

Output: Filled discovery document

Phase 2: Specification & Validation

Who: Markus (validator), Rafa (technical), Greg (product)

Steps:

• 1. Markus receives discovery inputs
• 2. Validate inputs against schema:

- All required fields present - Values conform to enums/formats - References are valid

• 3. Flag any missing or invalid data
• 4. Return to Greg/Rafa for clarification if needed
• 5. Approve validated inputs

Output: Validated data file

Phase 3: Scaffold Generation

Who: Markus (generator)

Steps:

• 1. Markus processes validated inputs
• 2. Generate scaffold:

- Create all required MDX files - Create all required JSON files - Bind templates based on page type - Generate navigation structure - Generate metadata

• 3. Validate generated output against specification
• 4. Commit to Git branch
• 5. Open PR for review

Output: Git branch with complete blueprint scaffold

Phase 4: Review & Approval

Who: Greg (design/product), Rafa (technical), Kristina (process)

Steps:

• 1. Team reviews PR:

- Is content accurate? - Does it follow the specification? - Are there any gaps? - Is the information well-organized?

• 2. Request changes if needed (back to Markus)
• 3. Greg approves PR (as owner of content/product)
• 4. Merge to main branch
• 5. CI/CD automatically deploys

Output: Deployed blueprint

Phase 5: Post-Launch

Who: Greg (content owner), Kristina (audit)

Steps:

• 1. Monitor analytics and feedback
• 2. Track issues or gaps
• 3. Plan iterations/improvements
• 4. Update content as needed
• 5. Archive if project ends

Content Update Workflow

For changes to existing blueprints:

• 1. Small updates (typo, clarification): Create PR directly, request Greg review
• 2. Significant changes (new section, major revision): Discuss with team first, create PR after alignment
• 3. Structural changes (template change, reorganization): Full review cycle with all stakeholders

All updates follow same quality standards as initial creation.

Review Checklist

Every blueprint review includes:

• [ ] All required pages present
• [ ] All frontmatter fields completed
• [ ] No placeholder text remaining
• [ ] Content is accurate and current
• [ ] Information is well-organized
• [ ] Links are internal and valid
• [ ] Images are optimized and credited
• [ ] Tone is consistent
• [ ] Follows specification exactly
• [ ] No broken links
• [ ] Mobile responsive (if using new components)
• [ ] Accessibility checklist passed

Approval Gates

Who can approve a PR:

• Content: Greg (design/product owner)
• Technical: Rafa (if architecture is involved)
• Process: Kristina (for governance changes)

All PRs require at least one approval from domain owner.

Deployment Checklist

Before deploying to production:

• [ ] PR approved by domain owner
• [ ] All CI checks passing (tests, types, validation)
• [ ] No broken links
• [ ] Changelog entry created
• [ ] Git commit message is clear

Version Control Strategy

• main branch: Always production-ready, always deployed
• feature branches: Work in progress, PR review required before merge
• Commit messages: Clear, descriptive, explain the "why"

All work must go through PR review before merging to main.

Rollback Procedure

If deployed content has issues:

• 1. Identify problem (usually from stakeholder feedback)
• 2. Assess severity:

- High: Rollback immediately - Medium: Fix in PR, merge, redeploy - Low: Add to backlog for next update cycle

• 3. Rollback if needed:

- git revert - Push to main - CI redeploys within 60 seconds

• 4. Fix actual issue in parallel on feature branch
• 5. Create PR with proper review cycle
• 6. Merge when ready

All rollbacks preserve Git history.

Feedback Loop

• Users find issues: Report via GitHub issues or email
• Team triages issues: Assigned to domain owner
• Domain owner fixes: Create PR, review, deploy
• Follow-up: Confirm fix with reporter

Issue resolution is tracked for continuous improvement.