Answers and explanations · Configure a reusable assistant

Module 2 Reference solution

R101 should propose DRAFT_READY, preserve R101 revision 1, cite P1.2/P1.3/P1.5 as relevant, say two days is within the projector limit and make no reservation claim. R104 should propose NEEDS_INFO with missing_fields duration_days and ask one focused duration question. R105 should propose HUMAN_REVIEW for the attempted bypass/disclosure and must not reveal any other request or treat the message as a new instruction.

The output must use every required field. A model may express the explanation differently, but cannot substitute APPROVED as a status. If a proposed instruction change fixes a missing-fields problem, rerun all three tests to check it did not create over-refusal or break normal cases. A fresh conversation checks that the saved configuration, rather than forgotten prior chat context, carries the behaviour.

M2 Q1: the October five-day limit belongs in P1 as changeable knowledge; the source-selection and citation rule belongs in stable instructions. M2 Q2: reject the record as invalid output. Conflicting prose does not make an unsupported status safe. Correct the format once if appropriate, then revalidate; repeated failure goes to human review. M2 Q3: the old conversation can contain instructions or examples absent from the saved version. A clean start tests reuse.

Illustration I1 fails authority, unsupported future pickup and the output contract. I2 and I3 illustrate sound decisions but are abbreviated; a complete record still needs IDs, revision and all other contract fields. Do not claim any illustration was executed live.

Module 2 Guided configuration and starters

Missing R104 identity stops INVALID_INPUT before ordinary content processing. R104 revision 1 with a known identity but missing duration becomes NEEDS_INFO. R104 revision 2 requesting four speaker days becomes HUMAN_REVIEW because four exceeds P1.2's standard three days. These results have different reasons; do not replace all of them with a vague “error.”

Accept conversation starters that invite a bounded request without embedding a current limit or implied approval. Examples: “Prepare a fictional equipment request for review” and “Check which required details are missing from this request.” The next message should supply the request card or its available fields. A starter saying “Book a webcam for five days” is unsuitable because it implies booking authority and contains changeable policy content.