Decide what an event needs to say
See this course’s project requirements
A local logging module that emits only allowed fictional event fields, redacts sample secrets, separates user-facing errors and passes a prohibited-field test.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Create an operational question and an explicit keep/exclude field table with reasons.
- Produce a structured JSON event and demonstrate rejection of undeclared vocabulary.
- Retain accepted endpoint and rejected type/format cases for the log fields.
- Produce distinct bounded user feedback and structured operational event examples.
- Retain actual emitted output assertions for approved shape and synthetic prohibited-marker absence.
- Deliver the tested local policy and distinguish proposed retention/access settings from implemented behavior.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Want more background?
The idea in everyday life
The fictional event is request_completed, status ok, duration_ms 25, request_id A-001. Files safe_events.py and test-safe-events.py use in-memory streams and inert fake secrets; no private data or external service is required.
A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance.
Decide what an event needs to say — original worked practice
A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance.
The fictional event is request_completed, status ok, duration_ms 25, request_id A-001. Files safe_events.py and test-safe-events.py use in-memory streams and inert fake secrets; no private data or external service is required.
1. Step 1
State the question: did a fictional request complete and how long did it take?
You should see: Outcome and duration are the required operational facts.
A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance.
2. Step 2
Read record: only event, status, duration_ms, and request_id are returned.
You should see: The permitted event fields are explicit.
A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance.
3. Step 3
Add fake email and token fields in the test case, then inspect the returned keys.
You should see: Extra fields are absent from the emitted record.
A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance.
4. Step 4
Write keep/exclude reasons for all six supplied field types.
You should see: A minimum-field logging decision table.
A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance.
What to finish
Create an operational question and an explicit keep/exclude field table with reasons.
Watch for this
Copying the whole input object to a log because it is convenient.
How can I tell I understand it?
Demonstrate the rule: A useful event answers a bounded operational question with minimum fields. Collecting a field merely because it is available increases exposure without proving relevance. Use the supplied variant to distinguish a changed result from a broken implementation.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.