{"id":323,"date":"2026-09-12T15:30:00","date_gmt":"2026-09-12T07:30:00","guid":{"rendered":"https:\/\/oribridge.org\/blog\/?p=323"},"modified":"2026-09-08T09:37:17","modified_gmt":"2026-09-08T01:37:17","slug":"ai-course-specification-not-teaching-method","status":"publish","type":"post","link":"https:\/\/oribridge.org\/blog\/ai-course-specification-not-teaching-method\/","title":{"rendered":"An AI Course Specification Is Not a Teaching Method"},"content":{"rendered":"

Public procurement documents can be unusually concrete. One specification asks for a course agent that manages question-and-answer pairs and can generate a presentation outline from input content. Another lists AI course hours, teacher materials and verification experiments for schools.<\/p>\n

An overseas expert may read those requirements and think: \u201cThe Chinese market wants this course.\u201d That is too fast. A specification tells you what one institution requested or described. It does not tell you how learners should be taught, what they will be able to do, or whether the same requirement exists elsewhere.<\/p>\n

The useful decision is to separate three objects: the technical asset, the teaching method and the learner evidence.<\/p>\n

What a specification actually gives you<\/h2>\n

The Shaanxi vocational-college procurement document includes requirements around a course-agent function, including management of course question-and-answer pairs and AI-generated presentation outlines. The Xin\u2019an compulsory-education equipment specification describes AI-themed course hours, teaching resources and verification experiments.<\/p>\n

These are observable requirements in named institutional contexts. They can help an expert notice that a potential buyer may care about assets, administration, classroom materials or practical verification. They can inform questions for a later discovery conversation.<\/p>\n

They do not prove that a foreign expert\u2019s existing course fits either institution. They do not prove that the requested functions work as intended. They do not establish a teaching sequence, assessment standard, budget benchmark or general demand.<\/p>\n

Three columns instead of one \u201ccourse\u201d label<\/h2>\n

Technical asset<\/h3>\n

What is being requested or described? A Q&A management function, a presentation-outline generator, a set of lesson materials, a number of course hours, or a verification experiment.<\/p>\n

This column should preserve the institution\u2019s wording and the scope conditions. It should not silently turn \u201csupports\u201d into \u201cteaches\u201d, or \u201ccontains\u201d into \u201cproduces mastery\u201d.<\/p>\n

Teaching method<\/h3>\n

How would a learner encounter the idea? Through a demonstration, guided practice, comparison, project, feedback loop, or supervised implementation? What misconception or failure would the lesson address?<\/p>\n

A procurement specification may leave this open. That is not a defect in the document; it is a reminder that the expert still has design work to do.<\/p>\n

Learner evidence<\/h3>\n

What can the learner produce or explain, and who reviews it? A completed Q&A set is not automatically a good teaching outcome. A generated presentation outline is not automatically a coherent lesson. A verification experiment needs a question, conditions, observation and interpretation.<\/p>\n

The three columns prevent an asset from masquerading as pedagogy.<\/p>\n

A scene: \u201cWe need an AI course agent\u201d<\/h2>\n

Imagine an institution showing an overseas expert the line \u201ccourse agent\u201d in a procurement document. The expert responds with a generic course about prompt engineering. The buyer asks how teachers will manage question pairs, review generated content and use the tool in a class. The expert has no answer because the product was built around a topic, not the specified work.<\/p>\n

The opposite response is also risky. The expert promises to reproduce every requested function before checking the environment, data, account and responsibility boundaries. A document has become an implementation commitment.<\/p>\n

A better research response is to ask which part is being purchased: a software function, a content asset, a training service, a support layer or a combination. Then ask what a teacher or student must do with it. The source helps formulate the questions; it does not answer them.<\/p>\n

Verification experiments are not automatically learning design<\/h2>\n

The Xin\u2019an specification\u2019s reference to verification experiments is useful because it signals a desire for practical checking. But \u201cexperiment\u201d can mean many things. Is the learner reproducing a known result? Testing a design? Comparing two approaches? Debugging a failure? Recording evidence for a teacher?<\/p>\n

An expert must choose the instructional purpose. If the goal is concept learning, a small controlled example may be enough. If the goal is project work, the experiment may need data, equipment, a rubric and a fallback. If the goal is procurement acceptance, the verification may belong to a technical test rather than a learner assessment.<\/p>\n

The public document does not resolve those choices. It should not be cited as proof that the expert\u2019s experimental method is approved.<\/p>\n

What the two documents cannot be combined into<\/h2>\n

It would be tempting to combine the two specifications and announce a general product: \u201cChina needs AI course agents plus 38 hours of verified AI lessons.\u201d That sentence would be unsupported. The documents belong to different institutions and scopes. Their requirements may be comparable as research prompts, not aggregated as a market total or universal curriculum.<\/p>\n

The same caution applies to a foreign expert\u2019s portfolio. A public request for course materials does not prove that a particular English course can be translated, that its rights are clear, or that its examples match the institution\u2019s curriculum.<\/p>\n

A product decision tree<\/h2>\n

Use the specification to choose among three next actions:<\/p>\n

Research only:<\/strong> The requirement is visible, but the buyer, environment and learner work are unknown. Record it with the source and limits.<\/p>\n

Adaptation brief:<\/strong> The buyer and learner are defined, but the existing course does not yet map to the requested asset or evidence. Build a gap list before translation.<\/p>\n

Technical or delivery discovery:<\/strong> The request includes an account, system, data, deployment or acceptance test. Open a separate scope with owners, conditions and stop rules.<\/p>\n

None of these actions is \u201cpublish a course because a specification exists.\u201d<\/p>\n

A counterexample: when the specification is enough for a narrow asset<\/h2>\n

If a buyer explicitly wants a set of teacher handouts matching a defined course-hour count and has supplied the learning objectives, the specification may be sufficient to draft a content-production brief. It still does not prove that the handouts produce learning results or that the expert can provide the associated platform function.<\/p>\n

Likewise, if the expert is only asked to review whether an existing course contains the requested topics, the specification can be a comparison input. Do not inflate a comparison into a delivery promise.<\/p>\n

The source-to-course check<\/h2>\n

Before an overseas expert uses a Chinese procurement specification in a product conversation, write five lines:<\/p>\n