Skip to content

Level 10 / Project 15 - Level 10 Grand Capstone

Home: README

Learn Your Way

Read Build Watch Test Review Visualize Try
Concept This project — Quiz Flashcards — —

Focus

  • Facade pattern composing 5 independent subsystems into a unified platform
  • Multi-tenant management with policy governance
  • End-to-end assessment: policy + readiness + architecture + change gates
  • Health scoring with subsystem-level breakdown

Why this project exists

Real enterprise platforms are compositions of specialized systems. This capstone integrates patterns from all 14 prior projects — tenant isolation, policy engine, change gates, readiness checks, and architecture fitness — into a coherent whole using dependency injection and protocol-based interfaces.

Run (copy/paste)

cd <repo-root>/projects/level-10/15-level10-grand-capstone
python project.py
pytest -v

Expected terminal output

{
  "overall": "AT_RISK",
  "health_score": 88.9,
  "total_checks": 9,
  "passed": 8,
  "warnings": 1,
  "subsystems": { "policy": [...], "readiness": [...], "architecture": [...], "change_gate": [...] }
}

Alter it (required)

  1. Add a ComplianceSubsystem that runs evidence collection checks (from project 05).
  2. Add a ChaosReadiness check that verifies chaos experiments have been run (from project 06).
  3. Add a dashboard-style output that shows each subsystem with a traffic-light status.

Break it (required)

  1. Run an assessment with empty context — observe multiple policy failures cascading to UNHEALTHY.
  2. Submit a high-risk change with an unready service — observe both change gate and readiness failures.
  3. Create an architecture with 50 services and high coupling — verify fitness checks flag it.

Fix it (required)

  1. Add subsystem-level health scores so you can identify which subsystem is dragging down the overall score.
  2. Add a minimum_checks_per_subsystem threshold — the platform should warn if any subsystem has zero checks.
  3. Test both fixes.

Explain it (teach-back)

  1. How does the Facade pattern keep subsystems decoupled while enabling end-to-end assessment?
  2. Why does the platform use a universal CheckResult type across all subsystems?
  3. How does the health score differ from a simple pass/fail count?
  4. If you were building this for a real company, which subsystem would you implement first and why?

Mastery check

You can move on when you can: - trace a full assessment through all five subsystems, - add a new subsystem and integrate it into the platform facade, - explain how Protocol-based interfaces enable loose coupling, - describe how this architecture maps to real enterprise platforms (AWS Well-Architected, Google SRE).

← Prev Home Next →