# Worked reference disclosure Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. Codex prepared the configurations, ran the commands and wrote this example after inspecting the supplied model, tests and known reference solution. It is not an unaided exercise completed by the profile owner. No human reviewer or participant feedback has been recorded. Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. # OpsProof — portable evidence pack Exported: 2026-10-07 **All content is self-reported. Origins and reviewer identities are not independently verified.** An evidence link or a recorded review does not establish professional proficiency, employment history, or hiring readiness. ## Target role Cloud operations reference example \(Codex-authored simulation\) Region / eligibility: Fictional role; no employer, country or work-authorization assessment. Additional requirements: Codex prepared the configurations, ran the commands and wrote this example after inspecting the supplied model, tests and known reference solution. It is not an unaided exercise completed by the profile owner. No human reviewer or participant feedback has been recorded. Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Missing evidence describes this artifact, not the profile owner’s capabilities. ## Requirement-to-evidence map 4 demo-selected requirements; 3 have linked records; 1 have missing evidence. Counts describe recorded links only; no quality, job-match or hiring score is calculated. ### 1. Diagnose a readiness mismatch and justify a focused configuration change within the local model. Record: demo-readiness | Priority: required | Selected for demo: yes Evidence status: Linked records; evidence quality not assessed Context / limits: Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Claim claim-demo-readiness → Artifact demo-diagnosis Connection to this requirement: A readiness-path mismatch explains the baseline simulated 404: the configured port matches the fixture at 8080, while /health does not match /ready. The wrong-port negative check instead produces CONNECTION\_REFUSED. This distinguishes those two causes inside this model; it does not rule out real network or application faults. Changing only readiness\_path to /ready passes candidate\_readiness but leaves capacity\_safety and rollback\_rehearsal failing. A green readiness result is insufficient for the three acceptance criteria. Claim limitations: Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. ### 2. Preserve the scenario’s three-replica permitted availability floor. Record: demo-capacity | Priority: required | Selected for demo: yes Evidence status: Linked records; evidence quality not assessed Context / limits: Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Claim claim-demo-capacity → Artifact demo-change Connection to this requirement: The baseline max\_unavailable=1 permits a modeled floor of 2/3 ready replicas, below the scenario requirement of 3/3. This is a computed policy allowance, not observed downtime or a production availability measurement. The complete change sets readiness\_path from /health to /ready, max\_unavailable from 1 to 0, and retain\_previous\_artifact from false to true. The candidate remains v2, the readiness port remains 8080, automatic rollback remains enabled and the rollback target remains v1. The model assumes a reserved surge slot; this was not provisioned or load-tested. Claim limitations: Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. ### 3. Rehearse recovery after the model injects a candidate failure and test negative recovery settings. Record: demo-recovery | Priority: required | Selected for demo: yes Evidence status: Linked records; evidence quality not assessed Context / limits: Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Claim claim-demo-recovery → Artifact demo-recovery-evidence Connection to this requirement: The final report passes all three checks: candidate readiness is 3/3 with simulated result 200; the permitted availability floor is 3/3; and the synthetic TIMEOUT rehearsal selects retained v1 and reports 3 recovered ready replicas. No elapsed recovery time or real service recovery was measured. Starting from the final configuration, port 8081 fails candidate\_readiness only; disabling automatic rollback fails rollback\_rehearsal only; targeting v2 for rollback fails rollback\_rehearsal only. The latter is a known-good-target guard, not evidence that this runner attempted a real rollback to v2. Claim limitations: Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. ### 4. Demonstrate a real-cluster rollout and recovery under production-like conditions. Record: demo-real-environment | Priority: context | Selected for demo: yes Evidence status: Missing evidence Context / limits: Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Missing evidence is a limit of this artifact, not an assessment of the user. ## Artifact records ### Baseline observations and partial-fix report Record: demo-diagnosis | Version: 1 Origin (self-reported): simulation Last edited: 2026-10-06T21:21:35.669Z External artifact URL (contents / ownership not verified): Not supplied Evidence summary: Inspect evidence/baseline.observe.stdout.txt, evidence/baseline.report.json, evidence/readiness-only.report.json and evidence/wrong-port.report.json. A readiness-path mismatch explains the baseline simulated 404: the configured port matches the fixture at 8080, while /health does not match /ready. The wrong-port negative check instead produces CONNECTION\_REFUSED. This distinguishes those two causes inside this model; it does not rule out real network or application faults. Limitations: Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. Exercise reference: rollout ### Three-field configuration change Record: demo-change | Version: 1 Origin (self-reported): simulation Last edited: 2026-10-06T21:21:35.669Z External artifact URL (contents / ownership not verified): Not supplied Evidence summary: Inspect evidence/baseline-to-final.patch, evidence/baseline.config.json and evidence/final.config.json. The complete change sets readiness\_path from /health to /ready, max\_unavailable from 1 to 0, and retain\_previous\_artifact from false to true. The candidate remains v2, the readiness port remains 8080, automatic rollback remains enabled and the rollback target remains v1. The model assumes a reserved surge slot; this was not provisioned or load-tested. Limitations: Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. Capacity is a computed floor under an assumed surge slot. Exercise reference: rollout ### Final verification and negative recovery checks Record: demo-recovery-evidence | Version: 1 Origin (self-reported): simulation Last edited: 2026-10-06T21:21:35.669Z External artifact URL (contents / ownership not verified): Not supplied Evidence summary: Inspect evidence/final.report.json, evidence/rollback-disabled.report.json, evidence/wrong-target.report.json and lab/rollout\_model.py. The final report passes all three checks: candidate readiness is 3/3 with simulated result 200; the permitted availability floor is 3/3; and the synthetic TIMEOUT rehearsal selects retained v1 and reports 3 recovered ready replicas. No elapsed recovery time or real service recovery was measured. Limitations: The rollback function is evaluated independently of successful candidate promotion and restores a hard-coded healthy v1 fixture. The capacity check is arithmetic rather than a scheduler. There is no real concurrency, traffic shifting, persistent state, database compatibility, resource scheduling, SLO, cloud cost or production incident in this artifact. Exercise reference: rollout ## Scoped review records No scoped reviews supplied. ## Application observations Manually entered observations cannot establish a causal effect on hiring outcomes. Timing, role, employer and many other factors differ. No application observations supplied. ## Original role text Diagnose a readiness mismatch and justify a focused configuration change within the local model. Preserve the scenario’s three-replica permitted availability floor. Rehearse recovery after the model injects a candidate failure and test negative recovery settings. Demonstrate a real-cluster rollout and recovery under production-like conditions. --- # OpsProof — Recover an unhealthy rollout Exported: 2026-10-07 **Status: Self-reported simulation. Not employment experience, a certification, or an independently verified assessment.** ## Target role Cloud operations reference example \(Codex-authored simulation\) Region / eligibility notes: Fictional role; no employer, country or work-authorization assessment. Selected practice areas: Linux, Python, CI/CD, Observability, Incident response Additional requirements and constraints: Codex prepared the configurations, ran the commands and wrote this example after inspecting the supplied model, tests and known reference solution. It is not an unaided exercise completed by the profile owner. No human reviewer or participant feedback has been recorded. Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Missing evidence describes this artifact, not the profile owner’s capabilities. ## Exercise scope A synthetic service changes its readiness path from /health to /ready during a rollout; both releases listen on port 8080. The old probe fails, and the supplied configuration also permits reduced availability and lacks the retained artifact needed for rollback. Preserve the intended release, keep three replicas available, and demonstrate recovery after an injected failure. All service behavior is simulated locally; this is not a Kubernetes cluster. Written evidence sections: 6/6 (completeness only; no quality or hiring score). ## Impact & observations The baseline observation reports v1 at 3/3 ready, the v2 fixture contract at port 8080 with readiness path /ready, and the configured /health probe returning the simulated result 404. Candidate readiness is 0/3. These are computed fixture outputs; no request was sent. The baseline max\_unavailable=1 permits a modeled floor of 2/3 ready replicas, below the scenario requirement of 3/3. This is a computed policy allowance, not observed downtime or a production availability measurement. The baseline keeps rollback\_on\_failure=true and rollback\_release=v1 but retain\_previous\_artifact=false. Its separate rollback rehearsal injects a synthetic TIMEOUT into v2 and reports no recovered release and 0 recovered ready replicas. ## Hypotheses & investigation A readiness-path mismatch explains the baseline simulated 404: the configured port matches the fixture at 8080, while /health does not match /ready. The wrong-port negative check instead produces CONNECTION\_REFUSED. This distinguishes those two causes inside this model; it does not rule out real network or application faults. Changing only readiness\_path to /ready passes candidate\_readiness but leaves capacity\_safety and rollback\_rehearsal failing. A green readiness result is insufficient for the three acceptance criteria. ## Decision & change The complete change sets readiness\_path from /health to /ready, max\_unavailable from 1 to 0, and retain\_previous\_artifact from false to true. The candidate remains v2, the readiness port remains 8080, automatic rollback remains enabled and the rollback target remains v1. The model assumes a reserved surge slot; this was not provisioned or load-tested. ## Validation & rollback The final report passes all three checks: candidate readiness is 3/3 with simulated result 200; the permitted availability floor is 3/3; and the synthetic TIMEOUT rehearsal selects retained v1 and reports 3 recovered ready replicas. No elapsed recovery time or real service recovery was measured. Starting from the final configuration, port 8081 fails candidate\_readiness only; disabling automatic rollback fails rollback\_rehearsal only; targeting v2 for rollback fails rollback\_rehearsal only. The latter is a known-good-target guard, not evidence that this runner attempted a real rollback to v2. Broken baseline \(baseline\): readiness FAIL; capacity FAIL; rollback FAIL; process exit 1. Config: evidence/baseline.config.json. Report: evidence/baseline.report.json. Readiness-only change \(readiness-only\): readiness PASS; capacity FAIL; rollback FAIL; process exit 1. Config: evidence/readiness-only.config.json. Report: evidence/readiness-only.report.json. Complete three-field change \(final\): readiness PASS; capacity PASS; rollback PASS; process exit 0. Config: evidence/final.config.json. Report: evidence/final.report.json. Negative check: wrong port \(wrong-port\): readiness FAIL; capacity PASS; rollback PASS; process exit 1. Config: evidence/wrong-port.config.json. Report: evidence/wrong-port.report.json. Negative check: rollback disabled \(rollback-disabled\): readiness PASS; capacity PASS; rollback FAIL; process exit 1. Config: evidence/rollback-disabled.config.json. Report: evidence/rollback-disabled.report.json. Negative check: wrong rollback target \(wrong-target\): readiness PASS; capacity PASS; rollback FAIL; process exit 1. Config: evidence/wrong-target.config.json. Report: evidence/wrong-target.report.json. baseline: configuration SHA-256 16970dda86682fff20771c5300a39af574e0666e09a78053abc6455187774a95; report SHA-256 f68ba3cdb6ddae8df0d01b6c5b589b17776c66865a03666ded8c09d5612f5b9b. readiness-only: configuration SHA-256 c94ee4066f4e29214cea59acf03e1ebfeb4b749d1a7a6c18764acd532036ae5f; report SHA-256 a46509ab7db637798f2e1eafb4ebdc798b3cc1dc540522cdd0b25ec4163b01b1. final: configuration SHA-256 5f71ab7b438dc7fb5d235ef1e62e4657c6fce6ff1a6781962c8422e093bc12a8; report SHA-256 d61730ae6204878d5bcb78a4f4d33ea82fa66f9d4d414121ab4db1c34c2b549e. wrong-port: configuration SHA-256 4dc61c46aa630973ec5ff43298a7a5ad4f22c6bd11b04dbed0c7e1106ae9460d; report SHA-256 dbe3ee19e60cffda3f32543380e0ee06b3c95c5b096048843e59a4b22e5bcbf3. rollback-disabled: configuration SHA-256 5ee1ee54c8aa477daf65a7cc6864f04f64ede42e9a54a918bb93ca26698fd460; report SHA-256 f5384f1021e2a1452298dd70aa5b5d135b0786a378f02b030da6fe7d320f8210. wrong-target: configuration SHA-256 acb97f6de06a410443616bc9a08f64d7c6090cc20d65091b6f3abc353028d204; report SHA-256 01c2ba912e63c892beb40b96918a419e20061349d0e71cdfa7d73ac9fa8ef1d4. The eight existing lab behavior tests passed. The five added reproduction-runner tests passed. The six case reports contain five intentionally failing configurations and one passing configuration; those expected failures are evidence, not a failed test suite. From this extracted showcase directory, run: python reproduce.py --output-dir ../../work/rollout-replay-new. Use a new or empty output directory outside lab and evidence; the runner preserves the shipped evidence, verifies source hashes, checks exact expected failures and report hashes, and reruns the eight lab tests. Python 3.10\+ and its standard library are sufficient. On Windows use py -3 or an absolute Python executable if python is unavailable. The manifest records command arguments, UTC timestamps, exit codes and SHA-256 values for source files, configurations and report bytes. Hashes identify the supplied bytes; editable files and locally generated hashes are not tamper-resistant verification or proof of authorship. lab/rollout.py: SHA-256 a724faafd86f639a0e352a3e5d946f49d6357cf85c5c6d7a1e847bd147180d29. lab/rollout\_model.py: SHA-256 f5d0de11267df802ae8e9c511024203f90d9f009173d07036301f0b3acb8dbba. lab/test\_rollout.py: SHA-256 772e1e49c595327ae79a829e4e96eb5d0cea6be14fbb1362346435ac1f55f9f3. lab/rollout.json: SHA-256 16970dda86682fff20771c5300a39af574e0666e09a78053abc6455187774a95. lab/test\_reproduce.py: SHA-256 4fae578dfef135fecc1453a14ca5d912e4c961fd68134d7dd0ee0a516eac7910. reproduce.py: SHA-256 15a35d356ae07f9483618686acb363f7ee1cc29d56f2d83affdc018d443f8bcf. ## Tradeoffs & limitations The rollback function is evaluated independently of successful candidate promotion and restores a hard-coded healthy v1 fixture. The capacity check is arithmetic rather than a scheduler. There is no real concurrency, traffic shifting, persistent state, database compatibility, resource scheduling, SLO, cloud cost or production incident in this artifact. Proposed next checks, not executed here: run an isolated real cluster; observe rollout and recovery with traffic; validate reserved capacity, timeout/backoff, database compatibility and concurrent failures; then choose an environment-specific recovery procedure. Passing this model alone cannot justify applying these settings to production. For a fresh personal attempt, work from the intentionally broken lab/rollout.json before reading the solution. Preserve your own outputs, explain a changed assumption, and disclose any reference or AI help. The supplied files are a worked reference, not a substitute for demonstrating your own reasoning. ## Tools, AI & collaboration Codex prepared the configurations, ran the commands and wrote this example after inspecting the supplied model, tests and known reference solution. It is not an unaided exercise completed by the profile owner. No human reviewer or participant feedback has been recorded. Selected for this fictional demonstration by Codex. The confirmed flags illustrate the mapping workflow; they do not record human confirmation or verification. Deterministic local Python simulation. No real HTTP, containers, Kubernetes, cloud resources, production traffic or human hiring assessment. ## Artifact reference No external repository URL supplied; inspect the bundled source files. ## Review notes (user-entered; not independently verified) Reviewer attribution: Not supplied Not supplied These unstructured legacy notes have no recorded review date, artifact version or identity verification. ## Reviewer checklist (not completed) - [ ] Evidence supports the diagnosis - [ ] Change addresses the failure without widening scope - [ ] Validation covers recovery, not just liveness - [ ] Rollback is reproducible - [ ] Limitations and assistance are explicit ## Original role text Diagnose a readiness mismatch and justify a focused configuration change within the local model. Preserve the scenario’s three-replica permitted availability floor. Rehearse recovery after the model injects a candidate failure and test negative recovery settings. Demonstrate a real-cluster rollout and recovery under production-like conditions. Keywords only suggest practice areas. Review requirements, geography, eligibility, experience and actual evidence manually. # Source evidence shared by both formats ## Inspect the source evidence Both formats link to these same local files. Relative paths travel with the extracted showcase. Workspace record URLs are intentionally blank because the artifacts are local files, not published repositories. - [Broken baseline configuration](evidence/baseline.config.json) - [Broken baseline report](evidence/baseline.report.json) - [Readiness-only change configuration](evidence/readiness-only.config.json) - [Readiness-only change report](evidence/readiness-only.report.json) - [Complete three-field change configuration](evidence/final.config.json) - [Complete three-field change report](evidence/final.report.json) - [Negative check: wrong port configuration](evidence/wrong-port.config.json) - [Negative check: wrong port report](evidence/wrong-port.report.json) - [Negative check: rollback disabled configuration](evidence/rollback-disabled.config.json) - [Negative check: rollback disabled report](evidence/rollback-disabled.report.json) - [Negative check: wrong rollback target configuration](evidence/wrong-target.config.json) - [Negative check: wrong rollback target report](evidence/wrong-target.report.json) - [Baseline observation](evidence/baseline.observe.stdout.txt) - [Three-field diff](evidence/baseline-to-final.patch) - [Command and hash manifest](evidence/manifest.json) - [CLI source](lab/rollout.py) - [Simulation source](lab/rollout_model.py) - [Reproduction runner](reproduce.py) - [Lab test source](lab/test_rollout.py) - [Runner test source](lab/test_reproduce.py) - [Lab test output](evidence/behavior-tests.stderr.txt) - [Reproduction-runner test execution record](evidence/runner-tests.record.json) - [Reproduction-runner test output](evidence/runner-tests.stderr.txt)