Completion Rubric¶
Page Maps¶
graph LR
family["Python Programming"]
program["Python Functional Programming"]
section["Reference"]
page["Completion Rubric"]
capstone["Capstone evidence"]
family --> program --> section --> page
page -.applies in.-> capstone
flowchart LR
orient["Orient on the page map"] --> read["Read the main claim and examples"]
read --> inspect["Inspect the related code, proof, or capstone surface"]
inspect --> verify["Run or review the verification path"]
verify --> apply["Apply the idea back to the module and capstone"]
Use this page when you need to decide whether functional-programming understanding is actually complete or only familiar.
Completion standard¶
You should be able to do all of the following:
- explain which part of a design is pure and which part is an effect boundary
- distinguish value modelling, failure modelling, and orchestration concerns clearly
- justify one choice about laziness, materialization, or retries without hand-waving
- name the proof route that would fail first if a claimed functional boundary drifted
- review a pipeline or capstone change in terms of ownership, dataflow, and proof
Course outcomes¶
| Area | Completion signal |
|---|---|
| purity and substitution | you can explain what changes when hidden state enters a function and why that matters |
| dataflow and composition | you can read a pipeline and name where transformation, aggregation, and coordination belong |
| failures as values | you can compare explicit failure modelling with exception-shaped ambiguity |
| effect boundaries | you can defend where adapters, resources, and async shells should start |
| sustainment | you can write one review judgment backed by one guide, one file, and one proof route |
Capstone evidence¶
Use these as the minimum capstone evidence:
make PROGRAM=python-programming/python-functional-programming capstone-walkthroughmake PROGRAM=python-programming/python-functional-programming capstone-testmake PROGRAM=python-programming/python-functional-programming test
Running them is not enough if you cannot explain what each route proved.
Reviewer questions¶
- Which package stays pure here?
- Which boundary owns the effectful part?
- Which failure is represented explicitly rather than hidden?
- Which proof route should another reviewer trust first?