Separate a study item from a decision request. A discussion can clarify options without producing a decision that nobody actually requested or had authority to make.

Two original items from one working group
Fictional project packet: shared knowledge base, originating working group WG1. No meeting, vote, or approval has occurred.
| Item | Purpose | Supplied material | Missing information |
|---|---|---|---|
| S1: navigation study | Compare topic-based and team-based navigation; no decision requested | Two original layout descriptions | User evidence about how people seek content |
| D1: content-review change | Consider moving review from November 6 to November 13 | Original date and requested new date | Launch impact, dependencies, decision authority and applicable meeting rules |
S1 can ask what evidence the working group needs next. It cannot acquire approval just because it occupies an agenda slot. Keep its status study; no decision requested.
For D1, November 13 is seven calendar days after November 6. The proposal changes the content-review date, not automatically the launch date. Keep November 6 as the baseline until an authorized decision changes it through the maintained process.
Make the decision ask explicit
Write the question as “Should the authorized decision body move content review from November 6 to November 13, subject to the documented launch and dependency impact?” The packet must establish which body has that authority, rather than assuming the steering committee does.
Record the relevant charter or delegation reference, authorized approver/body, and the actual attendance or decision rules it supplies. Leave these to confirm when absent. Do not borrow another institution's quorum or voting numbers to fill the gaps.
The SBCTC charter example separates study items, escalated items requesting decisions, and decision communication. Its historical organization-specific rules are reference context, not rules for this fictional project.
A proposed 45-minute agenda
- Previous actions, 5 minutes: Review what followed the last meeting's actual decisions, using the maintained records.
- Status changes, 8 minutes: Present changes relevant to scope, schedule, dependencies and escalation; avoid reciting every work item.
- S1 study, 10 minutes: Compare navigation options and identify the user evidence needed. Confirm that no immediate choice is requested.
- D1 readiness and discussion, 15 minutes: Check the requested date change, authority and missing launch-impact evidence. Identify what can be discussed and what must be resolved before a decision claim is supportable.
- Record and route, 7 minutes: Read back actual outcomes, outstanding requests, owners and the communication route to WG1.
The blocks total 45 minutes. This is an original allocation, not the meeting length or procedure required by a charter.
Prepare options without making the decision
For D1, compare retain November 6 with propose November 13. Ask WG1 to provide the review-work dependency and launch-impact evidence for each. Review support or additional staffing is another possibility only if its availability is supplied; do not invent capacity to make an option look feasible.
If authority or essential impact evidence is still missing, record the next information request. Do not mark the proposal approved on the strength of a readiness panel or an informal discussion.
Use a blank outcome record with item ID, actual decision or unresolved status, conditions, decision-maker/body, authority reference, date, follow-up owner, and communication recipient. Add evidence after the meeting; do not prefill a vote or approval. Route the result to WG1 through the organization's actual process.
Copy a decision-readiness agenda brief
Create one complete, self-contained US-English HTML companion for “WG1 · steering committee preparation packet”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for D1 · Review-date request; S1 · Navigation study; Restore original agenda times; Select text. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Draft a steering-committee agenda in US English.
Meeting length and project: [enter]
Study items and decision requests with originating group IDs: [paste]
Current baselines, proposals, options and evidence: [paste]
Launch/dependency impacts: [paste or TO CONFIRM]
Charter/delegation authority and actual meeting rules: [paste or TO CONFIRM]
Maintained agenda/minutes/decision log and communication route: [enter]
Separate study discussion from a specific decision request. Link origin,
ask, options and evidence gaps. Preserve baseline versus proposed changes. Display the governing authority inputs; do not invent quorum/voting rules,
approvers, capacity, impact, or actual decisions. Missing authority must not
produce an approval claim. Make phase times sum to the meeting length. Prepare blank decision/condition/decided-by/follow-up/route fields for actual use.
Return the agenda, readiness packet and blank record in the required format. If requested, provide a sanitized HTML facilitation-review copy revealing
study/decision evidence. No approve/reject controls, vote collection, automatic
notification, confidentiality guarantee, or replacement organizational records.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Steering Committee Agenda Template: Check the Decision Request Before Deliberating
A working group asks for an extra review week, but the packet does not say whether the committee can authorize the change or how it affects launch. Put the decision question, baseline, proposal, evidence gaps, and governing authority beside one another before calling the item ready for approval.
Separate a study item from a decision request. A discussion can clarify options without producing a decision that nobody actually requested or had authority to make.
## Two original items from one working group
**Fictional project packet: shared knowledge base, originating working group WG1. No meeting, vote, or approval has occurred.**
| Item | Purpose | Supplied material | Missing information |
| --- | --- | --- | --- |
| S1: navigation study | Compare topic-based and team-based navigation; no decision requested | Two original layout descriptions | User evidence about how people seek content |
| D1: content-review change | Consider moving review from November 6 to November 13 | Original date and requested new date | Launch impact, dependencies, decision authority and applicable meeting rules |
S1 can ask what evidence the working group needs next. It cannot acquire approval just because it occupies an agenda slot. Keep its status **study; no decision requested**.
For D1, November 13 is seven calendar days after November 6. The proposal changes the content-review date, not automatically the launch date. Keep November 6 as the baseline until an authorized decision changes it through the maintained process.
## Make the decision ask explicit
Write the question as **“Should the authorized decision body move content review from November 6 to November 13, subject to the documented launch and dependency impact?”** The packet must establish which body has that authority, rather than assuming the steering committee does.
Record the relevant charter or delegation reference, authorized approver/body, and the actual attendance or decision rules it supplies. Leave these **to confirm** when absent. Do not borrow another institution's quorum or voting numbers to fill the gaps.
The [SBCTC charter example](https://www.sbctc.edu/resources/documents/colleges-staff/it-support/ctclink/ctclink-steering-committee-charter.pdf) separates study items, escalated items requesting decisions, and decision communication. Its historical organization-specific rules are reference context, not rules for this fictional project.
## A proposed 45-minute agenda
1. **Previous actions, 5 minutes:** Review what followed the last meeting's actual decisions, using the maintained records.
2. **Status changes, 8 minutes:** Present changes relevant to scope, schedule, dependencies and escalation; avoid reciting every work item.
3. **S1 study, 10 minutes:** Compare navigation options and identify the user evidence needed. Confirm that no immediate choice is requested.
4. **D1 readiness and discussion, 15 minutes:** Check the requested date change, authority and missing launch-impact evidence. Identify what can be discussed and what must be resolved before a decision claim is supportable.
5. **Record and route, 7 minutes:** Read back actual outcomes, outstanding requests, owners and the communication route to WG1.
The blocks total 45 minutes. This is an original allocation, not the meeting length or procedure required by a charter.
## Prepare options without making the decision
For D1, compare **retain November 6** with **propose November 13**. Ask WG1 to provide the review-work dependency and launch-impact evidence for each. Review support or additional staffing is another possibility only if its availability is supplied; do not invent capacity to make an option look feasible.
If authority or essential impact evidence is still missing, record the next information request. Do not mark the proposal approved on the strength of a readiness panel or an informal discussion.
Use a blank outcome record with item ID, actual decision or unresolved status, conditions, decision-maker/body, authority reference, date, follow-up owner, and communication recipient. Add evidence after the meeting; do not prefill a vote or approval. Route the result to WG1 through the organization's actual process.
## Copy a decision-readiness agenda brief
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Read D1's baseline, request and unanswered questions with the facilitator before distributing the packet. Keep the actual agenda and decision record in the authorized organizational workflow, then send WG1 the documented outcome or the precise evidence request that remains.