Build the knowledge network first, then keep expanding

What must stay in persistent context, and what should be injected only when needed?

Which failures are really information-overload failures in disguise?

You can break one real workflow into persistent context, temporary task state, and optional evidence.

You can explain why a longer prompt is often a worse architecture decision.

Treating tokens as a billing-only concern.

Keeping every instruction and every example in the same permanent block.

What kind of answer should come from the model itself, and what must be grounded in retrieved evidence or tools?

When is the task too ambiguous for one pass and needs clarification or decomposition first?

You can classify a failure as capability, context, data, or tool access instead of calling everything a prompt issue.

You can design fallback behavior for tasks the model should not answer directly.

Assuming the model knows because the answer sounds fluent.

Expecting perfect recall or perfect reasoning without external support.

What output format can the system validate automatically?

Which instructions should live in prose, and which should become hard schema constraints?

You can replace a free-form response with a structured output contract for one real task.

You can explain why parsing should fail loudly instead of silently accepting malformed outputs.

Letting downstream code depend on natural-language phrasing.

Mixing policy, style, and output schema in one vague instruction block.

Which pieces of information should be stable across tasks, and which should be refreshed every time?

Where does evidence enter, expire, and get audited in the workflow?

You can rewrite one giant prompt into layers with separate update rules.

You can diagnose whether a bad answer was caused by missing evidence, stale state, or conflicting protocol.

Stuffing every rule, example, and task detail into one system prompt.

Keeping historical context forever without deciding what should expire.

What information should be retrieved on demand instead of stored in context?

How do you preserve citation, provenance, and freshness after retrieval?

You can describe a retrieval pipeline for one real workflow with query, ranking, and injection points.

You can explain when retrieval makes the system more reliable and when it only adds noise.

Dumping too many documents into the prompt without ranking or filtering.

Calling the workflow grounded without showing where evidence came from.

Which actions should require explicit evidence or confirmation before the model acts?

What is the failure order when the workflow depends on tools, providers, and gateway state?

You can run one tool workflow end to end and explain each dependency in the chain.

You can convert repeated operator actions into a reusable SOP or skill.

Installing more tools before the base chain is stable.

Trusting the UI alone instead of probing gateway, pairing, and tool readiness.

Which real failures should become the minimum eval set first?

What decision does each metric support: launch, rollback, or prioritization?

You can build a minimum eval set from your own live failures.

You can explain how an eval result changes product decisions instead of only making dashboards prettier.

Using abstract benchmarks that do not match the real workflow.

Treating vibes or one successful demo as evidence of improvement.

What must be logged to replay one bad run end to end?

Which failure label helps the team decide where to fix the system first?

You can produce one run trace that includes prompt, evidence, tools, output, and failure label.

You can describe a debugging order that starts with system state, not with guesswork.

Logging only the final answer and not the evidence or tool chain behind it.

Debugging by editing prompts before replaying the failure.

Which dimensions actually determine quality for this workflow: factuality, instruction following, citation, escalation judgment, or something else?

How do you write grader rules so a second operator or automated grader can reach similar conclusions?

You can define one rubric with dimensions, scoring anchors, and decision thresholds for a live workflow.

You can explain what changed when a system improves: not just the total score, but which dimension moved and why.

Reducing the whole workflow to one vague pass/fail judgment.

Keeping only an average score with no trace of which criterion failed.

Which instructions should never be overridable by user content or retrieved text?

Where should the system ask for confirmation before it acts or exposes sensitive data?

You can identify one prompt-injection or unsafe-action path in your own workflow and design a mitigation step.

You can explain the difference between policy text and enforceable system guardrails.

Treating safety text in the prompt as if it were enforcement.

Allowing retrieved documents or user uploads to override system authority.

Which layer should be optimized first: model choice, retrieval size, output length, or orchestration?

Where does the user actually notice latency, and what tradeoff is acceptable there?

You can identify the top two latency or cost levers in one workflow and propose a controlled experiment.

You can describe how compression, routing, caching, or smaller outputs change the system tradeoff.

Trying to optimize model cost before measuring retrieval waste or output bloat.

Reducing latency in ways that destroy evidence quality or trust.

Which documents are allowed to answer users, and how do you prove they are still current?

What metadata, owner, and refresh policy must exist before a document can become retrieval evidence?

You can define freshness classes, expiry thresholds, and owners for a real knowledge source.

You can explain whether one bad answer came from missing retrieval, stale retrieval, or missing governance rules.

Assuming indexing content once makes it safe forever.

Mixing drafts, old versions, and approved documents without clear precedence or metadata.

What should cause a hard stop: missing evidence, missing authority, elevated risk, or policy-sensitive requests?

What minimum handoff packet does the human reviewer need so the review queue is not blind and repetitive?

You can define a hard stop, review-queue owner, SLA, and handoff packet for one workflow.

You can explain why escalation is a quality path, not a product embarrassment.

Writing 'handoff to human if needed' without defining triggers or owners.

Escalating with no evidence packet, forcing the reviewer to reconstruct context from scratch.

What product behavior must change when the user is a guest, signed in, or subscribed?

Which events are the true source of entitlement state inside the app?

You can show the product behaving differently for guest, signed-in, and subscribed users.

You can explain why account state, billing state, and UI state must not drift apart.

Treating a success redirect as if it were the source of truth.

Letting auth, billing, and app state evolve independently.

What does the user take away besides content completion?

What product proof shows this is more than a stitched-together demo?

You can demo the full loop from learning to account state to premium access to saved knowledge assets.

You can explain the architecture choices and the hardest chain you had to close.

Shipping isolated feature pages without a product story or acceptance proof.

Publishing content without a method for practice, verification, and knowledge capture.