Seattle Independent Thinking
Seattle Schools: Keep Independent Thinking in AI Projects
A Seattle guide to evaluating AI outputs, testing code, keeping student ownership visible, and planning a practical grades 6–12 school assembly.
By Jim Jordan · · 4 min read
Easy-read summary
The big idea for Seattle, Washington schools
In Seattle, students can connect AI lessons to technology, design, maritime work, and community problem-solving. Familiarity with those industries does not mean every learner has the same devices, paid tools, or technical support at home. A strong school AI program begins with an equal opportunity to practice judgment. The central question is whether the student can explain and test a decision, not whether an output looks advanced. These project ideas are suggestions rather than Seattle Public Schools policy. Teachers should choose age-appropriate, approved tools and give a comparable route that does not require a student account or a family subscription.
Teach students to disclose AI help when a teacher or assignment requires it.
Use AI as a coach for questions, practice, feedback, and revision—not as a ghostwriter.
Verify important AI claims with reliable sources before sharing or submitting them.
Protect student privacy by avoiding personal, family, medical, or school-identifying details in prompts.
Section 2
Write the problem before opening a tool
Before asking AI for ideas, students write a short problem statement, the intended audience, and two constraints. A class designing a fictional school garden might identify limited space and a maintenance budget. A media class could identify an audience and a consent requirement. Students then sketch their own first approach. This preserves a record of original thinking and gives them criteria for reviewing later suggestions. Without criteria, the fluent answer can become the plan by default. The initial attempt does not need to be polished. Its value is showing what the learner noticed before receiving help and which questions still need investigation.
Section 3
Compare proposals against constraints
Provide two contrasting proposals and ask students to test each against their constraints. One might be attractive but inaccessible; another might meet the budget while ignoring maintenance. The class should explain why a proposal succeeds or fails rather than simply choose a favorite. If AI was permitted to generate possibilities, students identify which ideas they accepted, rejected, or changed. Keep factual claims separate from design preferences. A tool's recommendation is not evidence that a product is safe, affordable, or suitable. A final reflection should explain how the student's own criteria shaped the result and what information remains uncertain.
Section 4
Test code instead of trusting explanations
Coding projects need the same accountability. A student who submits generated code should be able to describe its inputs, explain a key branch, and demonstrate a test that catches a realistic failure. Teachers can supply a small program with an intentional bug for learners to investigate. Start with a prediction, run a test, inspect the result, and revise one thing at a time. This lesson can be completed without a chatbot. Students must not paste passwords, API keys, classmates' work, or private repository material into unapproved systems. Passing one happy-path example does not prove that a program handles empty input, unexpected values, or failure safely.
Section 5
Keep process evidence without surveillance
Use a few checkpoints that reveal learning: an initial plan, a rejected suggestion, a test result, and a final explanation. Do not confuse transparency with unlimited access to a student's personal accounts. Ask for task-specific evidence and respect school privacy rules. For students using approved assistive technology, distinguish support that improves access from assistance that performs the skill being assessed. If a concern arises, discuss the process and ask for a comparable demonstration. Tool access, confidence, and writing polish should not determine who is presumed honest. Consistent criteria help students understand both the freedom and the responsibility of an open-AI assignment.
Student prompt examples
- “Coach me, but do not complete the assignment for me.”
- “Ask me three questions before giving suggestions.”
- “Show what might be wrong or missing in this answer.”
Section 6
Make the assembly a launch for better projects
A Seattle AI school assembly with Jim Jordan can introduce a memorable sequence: define, question, test, and own the result. Send the office your grade band, audience size, date range, and project situations you want reinforced. Discuss whether teachers will attend and which classroom task will follow the keynote. Department teams can then adapt one existing assignment instead of creating a large new workload. Use the Washington speaker page and follow-up library below to connect the event with daily practice. Email office@jimmyai.ca to discuss a program that keeps curiosity and independent thinking at the center.
Action checklist
Use this after the assembly
- ●Create green, yellow, and red examples of acceptable AI help.
- ●Give students simple prompt language such as: coach me, do not complete it.
- ●Ask students to cite or explain how AI was used when appropriate.
- ●Revisit AI expectations during major writing, research, coding, and media projects.
Plan the next step for your school
Sources and citations