AI literacy capstone: publish a short brief readers can verify
Build a source register, claim ledger, and checked explainer that separates technical facts from a contextual recommendation.
Learning lesson · Reviewed October 2, 2026. Allow additional time for the practice. Prerequisites: all earlier AI & information literacy lessons. A browser and notes are enough; AI assistance is optional.
- Research a bounded technology question using primary documents.
- Separate direct evidence from interpretation.
- Produce an auditable brief with assumptions and an update trigger.
Your final task is to answer a bounded question: “When would a fixed tuple or a changing list suit a small Python program?” This question is narrow enough to research from official documentation, yet it still requires judgment. The docs can establish behavior; your example determines why that behavior matters for a particular task.
Build a source register before drafting
Open the Python tutorial on data structures and the built-in types reference. Locate the passages about lists, tuples, and mutable sequence operations. Record the document URL, relevant section, and the date you inspected it. A search snippet or an AI paraphrase is useful for locating a page, but the page itself supplies the evidence for the technical claim.
| Source | Relevant section | What it supports | What it does not decide |
|---|---|---|---|
| Python tutorial: Data Structures | Lists; tuples and sequences | Examples and distinction between the containers | The best architecture for every program |
| Python Built-in Types | Sequence and mutable sequence types | Supported operations and mutability behavior | Whether your particular record should change |
Use the register to keep source roles distinct. Both pages are official Python documentation, so they are authoritative for language behavior. They are not two independent experiments proving a productivity benefit. Counting links alone would confuse source quantity with the kind of evidence provided.
Write a claim ledger
| Draft claim | Classification | Review action |
|---|---|---|
| A list supports appending items | Technical fact supported by documentation | Cite mutable-sequence/list operations |
| A tuple prevents replacing its elements | Technical fact supported by documentation | Keep the precise scope |
| A tuple freezes every object inside it | Incorrect overstatement | Explain mutable inner objects |
| A list suits a growing queue of readings | Contextual recommendation | State the requirement that readings are added |
| Tuples are always faster | Unsupported broad performance claim here | Remove; do not infer a benchmark |
The recommendation follows from an explicit requirement: a growing collection needs to accept new items. It is an inference for that use case, not a quotation from the documentation and not a universal rule. A fixed pair such as coordinates may instead benefit from a tuple's fixed outer structure.
One bounded decision→Sources
Official behavior→Ledger
Fact or inference?→Brief
Example + limits
Test the example, including the subtle case
If your brief includes code, run it on a small example. This one deliberately shows that a tuple's outer structure and an object inside it are different things. You can also review it by tracing the operations on paper.
readings = [20, 21]
readings.append(22)
print(readings) # [20, 21, 22]
record = ("sensor-A", [20, 21])
record[1].append(22)
print(record) # ('sensor-A', [20, 21, 22])The tuple still contains the same two objects, but its inner list changes. The brief should avoid saying that tuples make all nested data immutable. This small counterexample is more informative than repeating a slogan about immutability.
A model brief to compare with your work
“Use a list for readings that you need to append as they arrive. Use a tuple when the outer group has a fixed shape, such as a pair of coordinates. Python documentation supports the difference in mutability and available operations. The choice here follows from the program's requirements; it does not imply that one container is always faster or safer. A tuple can contain a mutable list, so fixing the outer group does not freeze every nested object.”
This is an original illustrative brief. In your finished version, put the relevant source links beside the technical discussion and include your checked example. If AI helps draft it, retain the claim ledger and review every statement rather than treating drafting assistance as evidence.
Practice: produce your own 300–500-word brief
Choose either this container question or another similarly bounded technology concept. Deliver four items: a source register, a claim ledger with at least four claims, one worked example, and the short reader-facing brief. Include one limitation and one trigger for revisiting the piece, such as a change in the version or requirements used by your example.
Show the worked solution
A complete submission identifies the source sections, separates behavior from recommendation, includes the inner-list caveat, and reports the tested example. For an update trigger, write: “Review if the example changes from a fixed pair to a growing record, or if it begins relying on version-specific behavior.” A strong brief does not need extra length or more links when the bounded question is already answered.
Final self-review
Can a reader locate the source for each technical claim? Does the example support the recommendation? Have you named assumptions, avoided invented performance claims, and kept source text separate from instructions? Apply the rubric from the previous lesson. Completing this project demonstrates a review process on a small task; keep using that process as the questions become more complex.
Official sources checked October 2, 2026. Examples, exercises, and rubrics are original Noetrion teaching material; fictional datasets are identified below.