"The first algorithmic-design module has a narrow but important purpose. It introduces the moment when a circuit stops being only a collection of gates and becomes a structured question. Deutsch and Deutsch-Jozsa are ideal for that transition because they are small enough to inspect line by line and deep enough to expose the full algorithmic pattern: prepare a meaningful superposition, define an oracle contract, let the oracle encode structure into phase, and then use interference to make the hidden distinction observable. That pattern will reappear in later modules in richer forms, so it needs to be learned as a design story rather than as a historical anecdote.\n"
" By the end of this lecture you should be able to explain why the oracle is described as a promise-bearing contract, why the ancilla preparation matters, how phase kickback and interference divide the work, and how the Deutsch and Deutsch-Jozsa circuits are related as members of one family rather than as unrelated textbook diagrams. You should also be able to critique an implementation that runs but no longer matches the intended promise class.\n"
"Query problems are the right place to begin algorithmic design because they force you to state what the circuit is actually being asked to decide. In many beginner notebooks the learner adds gates and only later asks what information the circuit is supposed to reveal. Query algorithms reverse that habit. They begin with a decision task and then ask what circuit structure could make that task cheaper, cleaner, or more revealing. Deutsch is intentionally tiny, but it already demands professional discipline: what are the allowed functions, what promise are we relying on, and what counts as valid evidence that the circuit distinguished the promised cases?\n"
"The word oracle can easily become a source of confusion. In this course, an oracle is not a mystical black box and not a free pass to skip engineering. It is a reversible implementation of a function family with a stated interface and promise. That definition matters because every later design decision depends on it. If you do not know whether the oracle represents a constant case or a balanced case, or if you cannot explain how the oracle is wired into the surrounding preparation and readout stages, then the rest of the notebook becomes decoration around an undefined center. Good algorithmic design starts by making the center explicit.\n"
"The ancilla preparation in the Deutsch family is the first place where professional explanation must replace beginner myth. Preparing the ancilla in |-> is not a ritual. It is a mechanism that turns a reversible bit-flip response into phase information on the query branches. That is the whole point of phase kickback in this context. Once the oracle has written its answer into branch-relative phase instead of into a directly measured output bit, the final Hadamard on the query register can convert that phase pattern into a basis distinction. If you cannot narrate those two conversions clearly, you do not yet control the circuit.\n"
"Deutsch-Jozsa is then best read as a scaling move, not as a new kind of magic. The query register becomes wider, the promise class becomes a global statement about many inputs, and the final measurement pattern becomes a structured verdict on that promise. But the algorithmic skeleton stays the same. This is the pedagogical payoff of the module. You are not meant to memorize one two-qubit circuit and then a larger one. You are meant to notice which design ideas survive when the surface grows: superposition as a question format, the oracle as a contract, and interference as the readout mechanism.\n"
"There is also a subtle engineering lesson hiding inside these small circuits. In query algorithms, measuring the wrong wire or writing an ambiguous oracle helper can ruin the notebook even when the diagram still looks plausible. That is why this lecture keeps talking about reporting contracts and reviewability. Once algorithms enter the course, the danger of plausible nonsense increases. A circuit can look recognizably textbook and still fail the semantic burden of the problem. Professional growth means getting stricter about what exactly a rendered circuit is claiming.\n"
"The result is that the Deutsch family is less about its eventual practical value and more about the habits it installs. It teaches that algorithms are composed arguments. The preparation stage states the question format. The oracle stage injects promised structure. The interference stage extracts the useful distinction. The measurement stage reports only the claim-bearing evidence. If you can read and edit the family at that level, later algorithm modules will feel continuous instead of disconnected.\n"
" The anchor circuit below keeps the mechanism as bare as possible. Read the reference table first. Then inspect the editable code and make small changes. The goal is not to produce novelty yet. The goal is to make the mechanism legible enough that every line earns its place.\n"
"step_reference_table([{'marker': '[1]', 'code_focus': 'Prepare the query wire in superposition and the ancilla in the |-> state.', 'diagram_effect': 'The left side of the diagram separates the question register from the phase-sensitive ancilla.', 'why_it_matters': 'Without this preparation, the oracle behaves like an ordinary reversible gadget instead of a phase-encoding query.'}, {'marker': '[2]', 'code_focus': 'Apply an oracle that represents a promise class rather than a single numerical answer.', 'diagram_effect': 'The middle region becomes the semantic core of the circuit.', 'why_it_matters': 'Algorithmic design starts when you think in contracts and promise structures rather than in isolated gates.'}, {'marker': '[3]', 'code_focus': 'Use a final Hadamard on the query wire to convert hidden phase information into a measurable bit.', 'diagram_effect': 'The right side of the circuit shows a deliberate interference stage instead of direct readout after the oracle.', 'why_it_matters': 'Interference is the mechanism that cashes out the query advantage.'}, {'marker': '[4]', 'code_focus': 'Measure only the wire that carries the decision information.', 'diagram_effect': 'The reporting layer stays narrow and intentional.', 'why_it_matters': 'Professional design protects the evidence path and avoids measuring wires that are not part of the claim.'}])\n"
"quiz_block([{'prompt': 'Why is the ancilla prepared in the |-> state in the Deutsch circuit?', 'options': [\"So the oracle's bit flip appears as a phase on the query branch\", 'So the ancilla can be measured instead of the query wire', 'So the circuit uses fewer Hadamards'], 'correct_index': 0, 'explanation': 'The |-> preparation converts an oracle-controlled bit flip into phase kickback.'}, {'prompt': 'What does the final Hadamard on the query wire accomplish?', 'options': ['It compresses the circuit depth without changing meaning', 'It converts phase differences into a measurable basis distinction', 'It resets the ancilla before measurement'], 'correct_index': 1, 'explanation': 'Interference after the oracle is what reveals whether the promise is constant or balanced.'}, {'prompt': 'Why is it useful to describe the oracle as a contract?', 'options': ['Because the circuit depends on the exact gate library chosen by the backend', 'Because the algorithm reasons about a promise class, not an arbitrary implementation detail', 'Because all oracles must be measured to be trusted'], 'correct_index': 1, 'explanation': 'Oracle language keeps the emphasis on the function family and its promise, not on one ad hoc gate layout.'}], heading='Lecture Checkpoint A')\n"
"A good rule of thumb is that if you remove the words promise, oracle contract, or interference from your explanation and the notebook suddenly sounds vague, then the explanation was not yet strong enough. Those are not ornamental words in this module. They are the names of the burdens being carried by different regions of the circuit. The point of a lecture notebook is to make those burdens explicit before the lab asks you to disturb them.\n"
"Another useful habit is to ask what would count as a real refutation of your implementation. If a balanced oracle still reports the constant verdict, you have a meaningful failure. If your measurement mapping has drifted so the reported bit no longer corresponds to the decision wire, you also have a meaningful failure. This refutation mindset is what moves the module away from passive admiration and toward engineering control.\n"
"A serious lecture notebook has to teach more than recognition. It has to teach what to look at, what to ask, and what kind of evidence would count as a meaningful check. That is why this module keeps repeating a small number of disciplined questions. Which region prepares the state or question format? Which region encodes the task-specific structure? Which region translates that hidden structure into evidence you can actually read? And which parts of the notebook are presentation choices rather than mechanism? Those questions may sound repetitive, but repetition is useful here because algorithmic circuits become opaque very quickly when the learner loses the habit of dividing them into roles.\n",
"\n",
"Another reason for this slower lecture style is that professional design does not tolerate admiration as a substitute for analysis. It is perfectly possible to feel impressed by an algorithm, reproduce the overall diagram, and still be unable to explain what would break if one line changed. This course is trying to build the opposite habit. A mature notebook reader should be able to look at a circuit region and say what burden it carries, what evidence would test it, and what kind of mistake would falsify the current explanation. If that standard feels demanding, that is appropriate. The goal is to create designers, not spectators.\n"
"One reason these notebooks are written so densely is that later professional-design modules will assume this vocabulary is stable. When you later compare transpiled candidates, argue about noise sensitivity, or defend a capstone recommendation, you will not have time to rediscover what an oracle contract, reporting convention, controlled phase, or iteration choice means. The language has to be ready. That is why this lecture insists on precision now. The details are not there to slow you down forever. They are there so later speed is built on something trustworthy.\n"
"quiz_block([{'prompt': 'What changes when you move from Deutsch to Deutsch-Jozsa?', 'options': ['You stop using interference and switch to repeated measurement', 'You ask the same style of promise question on a larger query register', 'You no longer need an ancilla'], 'correct_index': 1, 'explanation': 'Deutsch-Jozsa scales the same interference logic to a promise on multiple inputs.'}, {'prompt': 'What is the professional-design danger in copying an oracle from memory?', 'options': ['The circuit may still run while no longer implementing the promised function family', 'The simulator will always reject the circuit', 'The compiler will remove the oracle automatically'], 'correct_index': 0, 'explanation': 'A remembered diagram can be gate-correct yet semantically wrong if the oracle contract is not explicit.'}, {'prompt': 'Why does the course keep asking what is being measured and why?', 'options': ['Because measuring more wires always increases accuracy', 'Because the reporting contract should track the actual claim the circuit is making', 'Because Qiskit cannot draw unmeasured circuits'], 'correct_index': 1, 'explanation': 'Good circuit design protects the evidence path as carefully as the quantum body.'}], heading='Lecture Checkpoint B')\n"
