CCA-F Exam Day — Part Three

Sam: So I have the domains, I have the cue list from the drills — honestly I feel like I have most of it. What is actually left?

Koko: Mostly you do have it. But here is the one thing worth ninety seconds before you walk in: coverage is not even. Four scenarios get drawn from a pool of six, and most practice material leans hard on the same four — customer-support agent, multi-agent research system, CI pipeline, code generation. Those four you have drilled. Two shapes get far less time in the wild, and if one of them lands, it is the one you have seen least.

Sam: Which two?

Koko: Developer productivity — an agent exploring an unfamiliar or legacy codebase — and document extraction: high volume, strict target schema, limited human review. Let me load each one in a breath and you tell me what sticks.

Sam: Go ahead.

Koko: Developer productivity first. The instinct the exam rewards is precision over breadth. Think of a new contractor arriving in a very large building: you do not inspect every room, you read the floor plan, find the corridor you need, and walk it. So: content search to find where something is called, path matching to find files by type, read incrementally along the execution flow rather than pulling everything in, delegate the verbose discovery tasks so the context window survives, and reach for a targeted edit anchored on a unique text string rather than rewriting a whole file.

Sam: So the one-line version is: navigate to the exact spot and make the smallest possible change.

Koko: Exactly that. The trap here is broad exploration — options that say things like 'load the full codebase first to understand the structure'. That costs the window and the exam knows it.

Sam: Good. And document extraction?

Koko: Document extraction is about honesty at schema level. The instinct is: the schema is a contract, not a template to fill in. So optional and nullable fields exist because a document may legitimately omit a value — that is not a failure. An explicit unclear or not-found value is always better than a guess. If a document shows both a stated total and a calculated total, you report both and let downstream decide. Retries carry the specific validation error, not just 'try again'. And confidence is calibrated per field, not one global score slapped on the whole extraction.

Sam: One-line version: incomplete is honest, guessed is not.

Koko: That is the line. The trap here is the option that fills every field — looks thorough, feels complete, gets the schema to validate — but has quietly invented a value where the document said nothing.

Sam: And the exam will make that option look very tidy.

Koko: Always. Tidy is the tell. If an extraction answer has no nulls and no unclear fields and the scenario description was ambiguous, something got fabricated. Pre-load both of these shapes before you sit down and neither one is a surprise.

Koko: Here is the one nobody warned you about. Some items on this exam ask you to do a small calculation. Not complex maths — just arithmetic, but under time pressure, and with a very specific shape. The one that recurs is what I call the batch-window sum.

Sam: I do not think part one or part two touched this at all. What is the shape?

Koko: Long asynchronous processing window, no latency guarantee, and a hard deadline. Your job is to find the latest moment you can submit and still guarantee results in time. The formula is simple: submission window equals deadline minus worst-case processing window.

Sam: Not minus the turnaround you observed in testing. Worst case.

Koko: Exactly. So work through the canonical example with me. Results are needed in thirty hours. Processing can take up to twenty-four. What is the submission window?

Sam: Thirty minus twenty-four is six. Everything has to be submitted within the first six hours.

Koko: Right. And if you are submitting continuously rather than in one shot, you slice that six-hour window so that no batch is ever launched later than worst-case processing allows. The window does not stretch just because your pipeline is fast today.

Sam: Here is what I want to pin down. In testing the system usually turns around in, say, four hours — so the typical window looks much more generous. Why is scheduling against the typical turnaround wrong?

Koko: Because 'usually fast' is not a contract. Think of it like a courier that says delivery within twenty-four hours but typically arrives in two. If you plan your whole day around the two-hour version and it takes twenty-three, you missed your meeting. The published worst-case window is the number with a guarantee attached. The typical turnaround has no guarantee attached.

Sam: And the option sitting next to the right answer will say something like 'schedule against the observed average processing time since that is representative of normal conditions.'

Koko: That is the trap. 'Representative of normal conditions' sounds defensible — it is just wrong, because the exam is testing whether you know the difference between an observed average and a published bound. The trap is specifically the word 'typical' or 'average' appearing in an otherwise well-constructed option.

Sam: So the instinct to train is: as soon as I see a deadline and a processing window together in the same stem, I do the sum on paper before I read the options.

Koko: Do it before you read the options. Get your number first, then find the option that matches it. If you read the options first, the average-based answer will look plausible because the arithmetic it implies is also technically correct — it just uses the wrong input. Write 'deadline minus worst case' at the top of your scratch space the moment the stem has both numbers in it.

Sam: Work it out loud, work it out twice, and commit to worst-case.

Koko: That is all there is to it. Small calculation, specific shape, one trap word. Do not let time pressure skip the arithmetic — it takes about twenty seconds and it is the only way to be certain.

Koko: Okay, candid moment. Parts one and two taught three rules hard — hard because that is how they stick — and each one has a boundary that neither episode got around to naming.

Sam: Which three?

Koko: Escalation, self-review, and ambiguity. Let's take them in order. Escalation first. Part one said escalate on the stated request, not on tone — and that is still right. But the full shape is three steps, not one.

Sam: Acknowledge, offer something real, then escalate when they reiterate.

Koko: Exactly. A first expression of dissatisfaction is not a request for a manager. It is a cue to acknowledge the frustration and offer a concrete resolution. The second ask — after you have actually offered something — that is the escalation trigger.

Sam: But an explicit request for a person is still immediate, full stop. That part doesn't soften.

Koko: Non-negotiable, yes. The nuance is only about the first grumble. The trap here is treating any frustrated sentence as a handoff trigger — you skip the offer, you escalate too early, and the exam marks it wrong because the person never got a real resolution attempt.

Sam: Right. On to self-review. Both episodes were pretty firm: independence beats effort, a session reviewing its own output is the weaker check. But that was specifically about correctness.

Koko: Good — you caught exactly the boundary. The rule holds when the question is did we miss a subtle defect. That is where independence matters, because the same reasoning that produced the error will tend to miss it. But there is a different job: checking whether a draft is consistently complete against explicit, concrete criteria.

Sam: Is the policy context there, are the timelines stated, is there a next step — that kind of checklist.

Koko: Right. That is a completeness check, and explicit criteria are a perfectly good tool for it. Think of it like a pilot's pre-flight list — you are not asking the plane to spot its own engine fault, you are running a structured confirmation that the known boxes are ticked.

Sam: So the discriminator is the question being asked: subtle defect gets independent review, consistent completeness can use explicit criteria self-directed.

Koko: That is the sentence to keep. The option sitting next to it on the exam will probably offer independent review for both jobs — and that sounds safe, but it is overkill when the criteria are concrete and the question is purely structural.

Sam: Last one — ambiguity. Part one said an ambiguous identity is a question for the person, not something the system resolves by picking the closest match. Stakes and reversibility are the discriminator there.

Koko: You named it before I got there. In an identity context, guessing wrong has consequences you cannot easily undo — wrong access, wrong record, wrong person. So you ask. But in a build task, low-stakes ambiguity is different.

Sam: State your assumptions and proceed, because nothing irreversible has happened and the person can correct you.

Koko: And they stay informed the whole time, which is what matters. The trap is applying the ask-always rule to a naming convention for a config file — you block progress on a question that a stated assumption would have resolved in one line.

Sam: So: ask when a wrong guess costs something you cannot take back. State and proceed when it does not.

Koko: That is it. Three rules, three boundaries. None of them cancel what parts one and two taught — they just tell you where the hard version stops and the nuance begins.

Sam: So these are the five things neither episode touched. Let me make sure I have the first one clean. No memory between calls — the whole conversation history gets resent every single time. Which means a long conversation is expensive not because anything is being stored, but because everything is being carried.

Koko: That is exactly it. Think of it like a courier who has no locker. Every delivery, you hand them the entire file from the beginning. The file gets thicker with every exchange, so every trip takes longer and costs more. That single fact is the mechanical reason behind everything we said in parts one and two about protecting context. It was never just tidiness — it is economics.

Sam: And the exam will frame questions around context length in terms of cost or latency, so understanding the mechanism is what gets you to the right answer rather than just pattern-matching on the word context.

Koko: Precisely. Next one — stop reasons. You already know the loop pair from part two. There are two more. One fires when the response hits the output limit, which means the model was cut off, not finished. The other fires when a stop sequence is encountered. The instinct the exam rewards: neither of those is a completion signal.

Sam: The option sitting next to the right answer will probably call the output-limit stop reason a successful completion, because the response did produce output.

Koko: Every time. The trap is conflating output with completion. If you hit the limit, you got a fragment. If you hit a stop sequence, you got a deliberate interrupt. Different things, same lesson: read the stop reason, do not assume.

Sam: Configuration file imports next. Files pull in other files by path, which is the actual mechanism behind the modular advice. Standards live in their own file and get referenced, not copied.

Koko: Right. Copying is a maintenance trap — you get drift. Importing by reference means one authoritative file and every config that needs it just points there. The exam will give you a scenario where someone has pasted the same block into four configs, then something changes. The instinct is: that structure belongs in its own file.

Sam: Skill naming — personal shadows team, silently. This one is subtle. You give a personal skill the same name as a shared team skill, your version wins, and you stop receiving any updates the team makes to theirs. No warning.

Koko: Silent shadowing. Like standing in front of a whiteboard — you block everything behind you and nobody tells you. The fix is simple: different name for personal variants. The trap the exam sets is a scenario where someone customised a skill and then complains they are missing team improvements. The question is why. The answer is the name collision, not a sync error, not a permission issue.

Sam: And last — batch identifiers. Each request in a batch carries an ID that ties the result back to the input, which is what lets you resubmit only the failures.

Koko: Without the ID, a failed batch means rerunning everything. With it, you resubmit just what failed. The exam phrases this as a reliability or efficiency question. The instinct is: the identifier is the mechanism that makes partial retry possible. The trap is framing retry as a property of the batch system itself rather than of the per-request ID.

Sam: Five clean facts. None of them long, all of them load-bearing on a question or two.

Koko: That is the point of this whole episode. Not new territory — just the gaps. On to the next block.

Sam: So we have all the pieces — the domains from part one, the signal-move-trap drilling from last time. What I want now is the order. When the clock is running and I am staring at an item, what do I do first, second, third?

Koko: That is exactly the right question to be asking three days out. Four steps. Each one can close the item early. Step one: before you read a single option, read the response-count line. How many answers does this item want?

Sam: And the reason that comes first is that you can pick the right two things in a three-answer item and still score zero because you missed the third.

Koko: Exactly. The count sets the frame for everything else. Get that wrong and the rest of your work is wasted. It takes three seconds and it has saved entire items.

Sam: Right. Step two is the operative verb.

Koko: Yes. Scan the stem for always, never, must, prevent, guarantee, reliably, consistently. If any of those are there, you are in deterministic territory. We drilled this last time — those words are a filter. Everything that is a reminder, a wording change, a request for more care, drops immediately. You are usually down to one or two options before you have really read them.

Sam: And the flip side: if the stem says improve, or tends to, or more consistent, then a hard deterministic option is likely the over-correction sitting in the list to catch people who do not notice the softened language.

Koko: Precisely. The verb in the stem is the dial that tells you how strong your answer needs to be. Match that strength. Step three is the one people most often skip under pressure.

Sam: The brief. The case brief that runs across the whole scenario block.

Koko: The same brief serves roughly fifteen items. An approval requirement, a latency ceiling, an audit obligation, who holds which authorisation — those are stated once and then tested repeatedly. The discriminator is often just sitting there from the first page.

Sam: And the trap version of this is an option that invents something the brief never gave you — a constraint that sounds reasonable but was not actually stated.

Koko: Which is wrong in exactly the same way that ignoring a real constraint is wrong. The brief is the contract. You do not add to it and you do not subtract from it. If an option requires a fact nobody gave you, it is out.

Sam: So after the brief check, if two options are still standing?

Koko: Step four. Ask which one still holds on a bad day. Not the ideal scenario — the degraded one, the partial failure, the three-a-m-on-a-holiday scenario. One of those two surviving options usually only works when everything is cooperating. That one goes.

Sam: Then commit. And before you mark the answer, read the response-count line one more time.

Koko: There it is. You brought it home yourself.

Sam: So the full run, in order: response count first, operative verb second, brief check third, bad-day test fourth, then count again before committing. Each step can end the item right there.

Koko: And that is the point. It is not a ritual you perform every time regardless — it is a series of early exits. Most items close at step two or three. Step four is for the ones that are genuinely close, and the bad-day question is what breaks the tie. The exam is built to reward the person who asks what holds under pressure, not what sounds good on a calm afternoon.

Sam: So that is actually it. Three episodes, and I feel like the last loose ends just got tied off.

Koko: That is the whole series — the briefing in part one, the signal-move-trap drills in part two, and this appendix. Nothing new goes in from here. If something new is trying to get in, close the door on it.

Sam: What do I do with the hour before the exam? Because that is the moment I always want to cram one more thing.

Koko: That hour belongs to exactly two things: the five domain sentences from part one, and the cue list from part two. That is it. No new material, no forum posts, no last-minute articles. You are not learning in that hour — you are warming up an engine that is already built.

Sam: Right. And if I had to compress everything we have done across all three episodes into a single line to carry into the room?

Koko: Here it is: the move is almost always the mechanism, not the wording. The exam will show you two options that both sound sensible, and the discriminator — which we drilled last time — is always the one that still holds when something goes wrong.

Sam: Predictable, recoverable, observable, honest about what it does not know.

Koko: That is the four-word filter. Every close call in that exam room runs through those four. If one option passes all four and the other only passes two, you have your answer.

Sam: What I am taking in is: stay with the mechanism, apply the four-word filter on every close call, and trust the cue list rather than re-reading the stem until it starts sounding like something else.

Koko: That last one is real. Stems do not get clearer the sixth time you read them — they get blurry. Trust the cue, run the move, go.

Sam: Good. I think I am actually ready.

Koko: You are. And here is the one administrative thing that sounds boring but matters: the day you pass, diary the twelve-month renewal. Not the week after, not when the reminder email arrives — the day you pass. Certified architect is not a shelf trophy; it expires, and the renewal is lighter than the original if you stay current.

Sam: Diary it the same day. Got it.

Koko: The flashcards for everything we covered across all three parts, and the practice quiz, are at KokoAI Academy — that is koko knows dot A I. Go there after the exam too, not just before, because the quiz will tell you which of the four filter words you are still soft on.

Sam: Koko, genuinely — thank you. All three of these.

Koko: Go show them what a well-designed system looks like. You have got this.