STEM Curriculum Written by Someone Who Taught It

Which STEM subjects do you build?

Mathematics from pre-algebra through calculus, linear algebra, statistics, and probability. Physics, mechanics and electricity and magnetism in particular. Chemistry at general and introductory organic levels. Computer science including programming fundamentals, data structures, and introductory algorithms. Data science and applied statistics, including practical work in Python. Electrical engineering including circuits, digital logic, and signals, plus general engineering design and applied technology.

Where a subject sits at the edge of that list we will say so and either bring in a subject matter expert or decline. The value of naming a list is that it is a real one.

How do you build labs that actually work in a real classroom?

By designing against the constraints that break labs, which are almost never the science. A lab fails because the equipment the school actually owns is not the equipment the lab assumed, because it needs more setup time than exists between periods, because the consumables cost more than the budget allows, or because it produces data too noisy for students to draw the intended conclusion.

So we ask what you have, what your period length is, what your consumables budget is, and what your safety constraints are, before designing anything. Every lab ships with a materials list priced against ordinary suppliers, a setup and teardown time estimate, expected results including realistic error ranges, and a troubleshooting section for when the data comes out wrong.

We also build a stated fallback for every lab. Equipment breaks and periods get shortened, and a lab with no degraded mode becomes a lost day.

How do you sequence problem sets so students actually build skill?

Deliberately, with the difficulty curve designed rather than accidental. The usual failure is a set that starts with three near-identical plug-in problems and then jumps to a multi-step problem requiring a synthesis nobody taught. Students who fail at that step conclude they are bad at the subject, when the sequence was bad.

We build from a worked example, to a near-transfer problem that changes one variable, to problems that change the surface story while keeping the structure, to genuine far-transfer problems that require choosing an approach rather than executing a given one. Each step is small enough that failure is diagnostic instead of demoralizing.

Answer keys include the common wrong answers and what mental model produces each one, so a teacher grading a stack of work can see the pattern rather than just the score.

Do you align to NGSS and state science and math standards?

Yes, and we hand over the map. For science that usually means NGSS three-dimensional alignment: the disciplinary core idea, the science and engineering practice, and the crosscutting concept, shown per unit rather than asserted in a cover letter. For mathematics it means the state or Common Core content standards plus the mathematical practices.

Three-dimensional science alignment is where a lot of purchased material is weakest. It is easy to cover a core idea while the practice dimension is decorative, meaning students read about investigation rather than investigating. We design the practice into the task, which is harder to write and is the point of the framework.

Can you build engineering and CTE curriculum for a technical program?

Yes, and this is a strong fit. Technical and career and technical education curriculum has to end in demonstrated competence at a task, which suits backward design well and suits our engineering background well.

For these programs we build around performance tasks and competency checklists rather than written exams alone, because the certifying question is whether the learner can do the job. We align to state CTE frameworks or to industry certification objectives where a certification is the target, and we build the lab and shop safety documentation that goes with hands-on work.

Do you build the software when a STEM course needs it?

Sometimes, and this is where the two halves of Claorova meet. Data science and computing courses often need a working environment, a dataset, an autograder, or a simulation, and a curriculum that assumes those exist without building them is unfinished.

We build custom software as our main line of work, so a simulator, a grading harness, an interactive visualization, or a clean teaching dataset can be part of the curriculum scope rather than a separate procurement. We will tell you plainly when an off the shelf tool already does the job better and cheaper, because usually one does.