{"schema":"starlight.intelligent_interfaces_course.v1","version":"1.0.0","title":"Intelligent Interfaces","url":"https://starlightintelligence.academy/academy/intelligent-interfaces","checkedOn":"2026-10-20","mode":"public-self-study","price":"free","author":"Frank Riemer / Starlight Intelligence Academy","truth":{"localDemonstration":true,"hostedModel":false,"accountProgress":false,"assessment":false,"certification":false,"providerEndorsement":false,"autoPublication":false},"lessons":[{"slug":"ask-for-the-right-interface","number":"01","title":"Ask for the right interface.","surface":"Chat","promise":"Turn a vague question into a visual you can use to make one decision.","artifact":"A visual brief and a first comparison","principle":"Choose the representation from the decision.","explanation":["A visual is useful when it exposes a relationship that prose makes difficult to inspect. Compare alternatives on the same criteria; trace dependencies through a system; explore a variable when its effect matters. Start by naming the decision, the reader and the evidence. Material, typography and motion come after that structure.","Automatic Intelligent UI is a Chat capability. The separate @Visualize plugin can make supported interactive visualizations in Chat and Work on web. Their output, availability and persistence differ. A prompt can request a form, but it cannot guarantee the host will render it. Keep a readable table or explanation as the fallback.","Predict your preferred answer before asking. Then look for a fact the visual reveals that would change it. This makes the visual an instrument for judgment rather than a decorative confirmation of your initial view."],"example":"A founder choosing between a weekly report, a support triage and a content brief should compare frequency, source access, review burden and consequence of error. Invented ROI scores would obscure the decision. A source-access column with an explicit unknown makes the next action clear.","prompt":"Help me choose one recurring workflow to improve: weekly research brief, support triage, or content production. First ask for missing evidence that changes the choice. Then render a compact comparison using the same criteria: recurrence, source access, review burden, consequence of error, and first useful artifact. Distinguish supplied facts, assumptions and unknowns. Let me change one decision-relevant input when supported. Give a readable fallback. End with the smallest reversible test.","practice":"Use three real workflows from your own week. Write down your predicted choice, request the comparison, and name the single observation that changed or confirmed it.","checks":["The alternatives use the same criteria.","Unknown evidence stays visibly unknown.","The chosen interface exposes a decision-relevant relationship.","A reader can understand the result without interaction or color."],"transfer":"Repeat with a household or community decision using different criteria. Explain why the original representation still fits—or replace it.","sources":["intelligent-ui","visualize","work"]},{"slug":"direct-a-visual-workbench","number":"02","title":"Direct a visual workbench.","surface":"Work","promise":"Make an inspectable interactive artifact with real states and a portable original.","artifact":"An HTML prototype and a review note","principle":"Specify behavior as precisely as appearance.","explanation":["An effective visual brief names what the reader should understand, which controls change the answer, and what must remain visible. Request the smallest interaction that teaches the relationship. A comparison needs shared columns; an explorer needs meaningful inputs and visible consequences; an architecture view needs ownership and failure paths.","In Work, request a finished artifact: a self-contained HTML explainer, an authored SVG, a spreadsheet, or a document with embedded figures. Use @Visualize when the host supports that preview. A screenshot preserves appearance; the HTML and source data preserve the artifact. Ask for both when you need portability.","Liquid glass is a material treatment. Use it on navigation and shallow surfaces while keeping reading planes opaque enough for contrast. Require a small-screen layout, visible focus, text alternatives and a reduced-motion path. An attractive first frame does not establish that the controls work."],"example":"A workflow explorer lets the reader select read-only preparation or an external action. The approval boundary changes visibly. The interface explains the rule with text, and the same information survives as a static table in the exported brief.","prompt":"Build a self-contained HTML learning workbench for my supplied workflow. Show inputs, preparation, review and output. Add one meaningful control that changes the approval boundary, with a text explanation of the change. Use Starlight's obsidian, restrained ice-blue, editorial typography and shallow smoked glass. Keep body text on a high-contrast plane. Support 320px, keyboard, 200% zoom and reduced motion. Include loading, empty and failure states only where a real operation needs them. Label synthetic examples. Return original HTML, supplied data, a screenshot when supported, and a concise inspection note. Do not make external calls or invent an integration.","practice":"Build a two-state prototype with your own workflow. Use every control with a keyboard, then explain the same decision in a static paragraph.","checks":["Every visible control changes a meaningful state.","All data and examples are attributed or labeled synthetic.","The original artifact is downloadable and opens independently.","Meaning survives narrow width, keyboard use and reduced motion."],"transfer":"Replace the workflow with one from another person. Keep the interface only when it still explains their decision.","sources":["visualize","work"]},{"slug":"build-with-codex-and-skills","number":"03","title":"Build with Codex and skills.","surface":"Codex","promise":"Move from an attractive prototype to a tested change in the owning repository.","artifact":"A bounded patch, checks and preview","principle":"Give the builder acceptance evidence.","explanation":["Codex needs the actual source, the intended outcome and the constraints that define a good change. Read AGENTS.md and existing patterns before choosing a new dependency. Supply the visual target alongside the behavior it represents. Keep an approved prototype and the production implementation tied to explicit revisions.","A reusable skill packages a repeatable method and its resources. A plugin can bundle skills and tool connections. Neither grants permissions by existing as a Markdown file. Reuse Starlight's installed architecture and design capabilities when available, then verify the real host binding instead of inventing an @name.","Ask for a vertical slice: a working input, a meaningful result, recovery and export. Checks must inspect behavior and failure states. A successful build establishes compilation; a preview establishes a hosted candidate. Production and user usefulness need their own evidence."],"example":"A comparison prototype becomes a server-rendered course page with a small client workbench. The repository already provides navigation, security headers and typography. Reusing them avoids a competing application shell and makes the new learning surface discoverable.","prompt":"Implement this reviewed visual artifact in the repository that owns the production route. Read applicable AGENTS.md, architecture decisions, dependencies and release instructions. Record the exact base revision. Reuse installed Starlight AI Architect and relevant design/verification skills when present; report unavailable bindings. Preserve unrelated changes. Implement one complete interaction with accessible narrow-screen, keyboard, error and export behavior. Run the required repository checks and inspect a Git-backed preview. Return the patch, actual check results, preview source SHA, rollback and unresolved limitations. Release only within my authorized scope and the repository's acceptance gates.","practice":"Give Codex an existing repository and your prototype. Before implementation, freeze three observable acceptance statements and one failure case. Compare the final preview against them.","checks":["The owning repository and exact base revision are recorded.","Existing identity, billing and runtime boundaries remain coherent.","Checks cover the chosen interaction and at least one failure.","The preview is tied to the actual candidate source."],"transfer":"Package only the repeatable part as a skill proposal. Test it on a second artifact before calling it reusable.","sources":["agents-md","skills","work"]},{"slug":"design-an-api-backed-interface","number":"04","title":"Design an API-backed interface.","surface":"API","promise":"Understand how typed model output becomes dependable product UI.","artifact":"A component contract and a mocked integration","principle":"The model proposes; the application owns the interface.","explanation":["Treat model output as data with a contract. Validate its shape, map it to an allowlisted component, and preserve source identifiers. Never execute arbitrary model-produced HTML in your authenticated application. Render loading, partial results and retry states deliberately rather than letting streaming text dictate the entire interaction.","Vercel AI SDK documents generative interfaces built from tool results and UI components. OpenAI's current plugin documentation describes UI resources for MCP tools inside ChatGPT, with feature-detected MCP Apps support. Neither is a claim that ChatGPT's automatic Intelligent UI can be exported as your product API. Choose the route from where the customer works.","Evaluate frontier capabilities in an isolated lab with a stable fallback. The AI Elements site currently announces a move to shadcn/ui and deprecation at the end of November 2026. Workflow and Sandbox have their own lifecycle, access and cost rules. Do not upgrade the whole production stack to follow a course example. Check current official docs and pin the versions used by the actual build."],"example":"A research tool returns title, source URL, checked date and a bounded summary. A validated result maps to a research card. Missing source data produces an explicit incomplete state. A fixture can test this rendering without a live model or API key.","prompt":"Design a typed research-card integration using the repository's current stack. Begin with local fixtures: valid, missing source, invalid shape, partial result and provider failure. Define an allowlisted result schema, validate on the server, and map it to accessible application-owned components. Show sources, checked dates and uncertainty beside claims. Use current official OpenAI and Vercel documentation; distinguish stable capability, beta access and a proposed experiment. Preserve the existing orchestration owner. Keep secrets server-side, set a request budget and cancellation path, and require explicit opt-in before a billable live call. Do not execute model-produced markup.","practice":"Write the result schema and five fixture states. Build the component without an API call. Add a live adapter only after the fixture behavior and budget boundary are accepted.","checks":["Untrusted output is validated before rendering.","A denied or failed request has an understandable recovery state.","Version, source date, access and cost assumptions are explicit.","No API key or private context enters a client bundle."],"transfer":"Replace the research card with a planning or creative component while keeping the same trust boundary.","sources":["generative-ui","responses","apps","elements","workflow","sandbox","gateway"]},{"slug":"teach-through-prediction-and-proof","number":"05","title":"Teach through prediction and proof.","surface":"Work","promise":"Turn an impressive output into a learning experience another person can repeat.","artifact":"A worked example, critique and transfer attempt","principle":"Make the learner's judgment visible.","explanation":["Begin with a concrete task and an unaided prediction. Show the relevant source and ask the learner to make a choice. Offer a hint before the complete worked example. Then compare the first attempt, revise one decision and repeat on a different case. This course adopts that sequence as a teaching design, not a claim of measured learning gains.","An AI teaching team should have complementary jobs: the architect identifies a mechanism, the builder produces an artifact, and a reviewer challenges it against frozen acceptance. These responsibilities can be prompts within one host or a bounded team where supported. Names and illustrated faculty are teaching identities; they do not prove a hosted multi-agent runtime.","Let the learner carry the original work, source trail and critique into their own agent. The Academy's existing connect, installation and evaluation routes provide continuity. A self-reported check is useful practice evidence, not a credential or independent assessment."],"example":"Before revealing a workflow map, ask which operation requires review. After the learner answers, show the authored boundary and explain it. A second case changes from drafting a message to sending it, so the learner must apply the rule rather than repeat the earlier label.","prompt":"Teach this workflow through one decision at a time. First ask me for an unaided prediction and a reason; wait for it. Then show only the source evidence I need. Give a hint before a worked example. Compare my answer to the authored example without treating disagreement as a verified assessment. Ask for one revision and a fresh transfer case. Keep original and revised reasoning distinct. Use Starlight's available learning, architecture and review skills only within their actual tools and permissions. End with a portable practice note containing artifact, sources, changes and unresolved questions.","practice":"Teach a peer one approval-boundary decision. Preserve their initial reasoning, the hint and the revision. Use a fresh case to test whether the explanation transfers.","checks":["Prediction precedes the worked answer.","Hints preserve a meaningful learner decision.","First attempt and revision remain distinguishable.","Transfer uses a different case and makes no certification claim."],"transfer":"Use the same learning sequence for a design or source-quality decision instead of an approval boundary.","sources":["skills","work"]},{"slug":"record-the-build-and-distribute","number":"06","title":"Record the build. Publish the proof.","surface":"Work","promise":"Turn one actual artifact into a useful demonstration and a searchable lesson.","artifact":"A recording brief, original assets and publication draft","principle":"Show the mechanism before the claim.","explanation":["Capture the transformation: the question, the exact prompt, the visual result, one meaningful interaction and the accepted artifact. Keep a visible correction when it teaches something. A short demonstration should make one useful promise and show the evidence for it. Do not turn a mock into a live integration through editing.","For a Windows workflow, record the browser or editor with an available screen recorder such as OBS or an already-owned capture tool. Capture a clean 16:9 master and a deliberate portrait crop; review legibility at phone size. Add edited captions and a written transcript. OpenAI Record & Replay is a separate computer-use workflow feature on supported macOS setups, not a general video production recorder.","Publish an original answer-first lesson with an exact title, a useful worked example, primary references, a checked date and a link to the runnable artifact. Add chapters and a transcript when the actual video exists. Structured data must describe what is visible; add VideoObject only after publishing the real recording. Search and answer-engine visibility are experiments measured through qualified visits and useful artifacts, not guaranteed rankings."],"example":"A 60-second film opens on the finished comparison, shows the brief that created it, changes one input, then reveals the exported review note. Its single action is to open this lab and build a comparison with the viewer's own workflow. A longer edition explains the correction and production checks.","prompt":"Use this actual artifact and its accepted evidence to prepare a recording package. Produce a 60-second script with five timed shots, a six-minute walkthrough outline, caption text, transcript draft, three accurate titles and one useful call to action. Separate captured proof from shots still needed. Show the input, prompt, one interaction, a limitation and the portable result. Draft an answer-first lesson with primary references, checked date, accessible image descriptions and relevant internal links. Name providers as technologies used; describe any collaboration or partnership only with owner-approved substantiation. Keep publication and external messages pending until separately authorized.","practice":"Record the five shots from the course recording studio. Check every visible claim against the actual recording, then publish only after reviewing captions, rights and the destination.","checks":["Every capability shown actually ran or is labeled a demonstration.","No private prompts, account details or credentials appear.","Captions and a written equivalent preserve the teaching.","The call to action opens a relevant usable artifact; affiliation language is substantiated."],"transfer":"Repeat with a different artifact and one unfamiliar viewer. Observe where they hesitate before revising the next edition.","sources":["replay","work","visualize"]}],"prompts":[{"title":"Compare with evidence","kind":"comparison","surface":"Chat","note":"Shared criteria. Explicit unknowns.","prompt":"Compare my alternatives on the same decision-relevant criteria. Separate facts, assumptions and unknowns; attach sources to factual claims. Render a compact comparison and let me change one useful input when supported. Give a readable fallback and the next reversible test."},{"title":"Reveal the system","kind":"system","surface":"Work","note":"Ownership, dependencies, recovery.","prompt":"Map this system as a compact, labeled interactive diagram when supported. Show the owner, inputs, transformations, external actions and failure/recovery boundaries. Let me inspect a node without hiding the whole system. Supply a static text equivalent and original SVG or HTML."},{"title":"Explore a trade-off","kind":"explorer","surface":"Chat","note":"Change an assumption. See the effect.","prompt":"Build a small interactive explorer for this trade-off. Use only supplied data or clearly labeled assumptions. Expose at most two meaningful controls, show units and uncertainty, and explain the selected state. Do not invent measured precision. Include the underlying formulas and a static fallback."},{"title":"Teach one decision","kind":"story","surface":"Work","note":"Predict, inspect, revise, transfer.","prompt":"Teach this workflow through one decision at a time. First ask me for an unaided prediction and a reason; wait for it. Then show only the source evidence I need. Give a hint before a worked example. Compare my answer to the authored example without treating disagreement as a verified assessment. Ask for one revision and a fresh transfer case. Keep original and revised reasoning distinct. Use Starlight's available learning, architecture and review skills only within their actual tools and permissions. End with a portable practice note containing artifact, sources, changes and unresolved questions."},{"title":"Art-direct the artifact","kind":"story","surface":"Work","note":"Editorial glass. Readable at 320px.","prompt":"Build a self-contained HTML learning workbench for my supplied workflow. Show inputs, preparation, review and output. Add one meaningful control that changes the approval boundary, with a text explanation of the change. Use Starlight's obsidian, restrained ice-blue, editorial typography and shallow smoked glass. Keep body text on a high-contrast plane. Support 320px, keyboard, 200% zoom and reduced motion. Include loading, empty and failure states only where a real operation needs them. Label synthetic examples. Return original HTML, supplied data, a screenshot when supported, and a concise inspection note. Do not make external calls or invent an integration."},{"title":"Ship the vertical slice","kind":"system","surface":"Codex","note":"A real patch with release evidence.","prompt":"Implement this reviewed visual artifact in the repository that owns the production route. Read applicable AGENTS.md, architecture decisions, dependencies and release instructions. Record the exact base revision. Reuse installed Starlight AI Architect and relevant design/verification skills when present; report unavailable bindings. Preserve unrelated changes. Implement one complete interaction with accessible narrow-screen, keyboard, error and export behavior. Run the required repository checks and inspect a Git-backed preview. Return the patch, actual check results, preview source SHA, rollback and unresolved limitations. Release only within my authorized scope and the repository's acceptance gates."},{"title":"Prototype the API boundary","kind":"system","surface":"API","note":"Typed fixtures before live spend.","prompt":"Design a typed research-card integration using the repository's current stack. Begin with local fixtures: valid, missing source, invalid shape, partial result and provider failure. Define an allowlisted result schema, validate on the server, and map it to accessible application-owned components. Show sources, checked dates and uncertainty beside claims. Use current official OpenAI and Vercel documentation; distinguish stable capability, beta access and a proposed experiment. Preserve the existing orchestration owner. Keep secrets server-side, set a request budget and cancellation path, and require explicit opt-in before a billable live call. Do not execute model-produced markup."},{"title":"Shoot the build","kind":"story","surface":"Work","note":"Five shots. One useful action.","prompt":"Use this actual artifact and its accepted evidence to prepare a recording package. Produce a 60-second script with five timed shots, a six-minute walkthrough outline, caption text, transcript draft, three accurate titles and one useful call to action. Separate captured proof from shots still needed. Show the input, prompt, one interaction, a limitation and the portable result. Draft an answer-first lesson with primary references, checked date, accessible image descriptions and relevant internal links. Name providers as technologies used; describe any collaboration or partnership only with owner-approved substantiation. Keep publication and external messages pending until separately authorized."}],"sources":[{"id":"intelligent-ui","publisher":"OpenAI","title":"Intelligent UI in ChatGPT","url":"https://help.openai.com/en/articles/20001598-intelligent-ui-in-chatgpt","use":"Automatic answer composition in Chat; availability and state boundaries."},{"id":"work","publisher":"OpenAI","title":"ChatGPT Work and Codex","url":"https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex","use":"Choose a surface by the task; account and rollout access vary."},{"id":"visualize","publisher":"OpenAI","title":"Visualizations","url":"https://learn.chatgpt.com/docs/visualizations","use":"The separate @Visualize capability in supported Chat and Work on web; snapshots are not live dashboards."},{"id":"skills","publisher":"OpenAI","title":"Build skills","url":"https://learn.chatgpt.com/docs/build-skills","use":"Reusable instructions and supporting resources; installation and tool authority are separate."},{"id":"agents-md","publisher":"OpenAI","title":"Custom instructions with AGENTS.md","url":"https://developers.openai.com/codex/agent-configuration/agents-md","use":"Repository guidance before implementation."},{"id":"responses","publisher":"OpenAI","title":"Structured outputs","url":"https://developers.openai.com/api/docs/guides/structured-outputs","use":"Application integration; API billing and credentials are separate from a ChatGPT plan."},{"id":"apps","publisher":"OpenAI","title":"Add UI to your MCP server","url":"https://developers.openai.com/plugins/build/chatgpt-ui","use":"A distinct route for an application UI inside ChatGPT; not an export of Intelligent UI."},{"id":"generative-ui","publisher":"Vercel","title":"Generative user interfaces","url":"https://ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces","use":"Map typed tool results into application-owned components."},{"id":"elements","publisher":"Vercel","title":"AI Elements","url":"https://elements.ai-sdk.dev/","use":"Component reference. Current notice: moving to shadcn/ui, with deprecation announced for end of November 2026; recheck before adoption."},{"id":"workflow","publisher":"Vercel","title":"Workflow","url":"https://vercel.com/docs/workflows","use":"Durable execution option to evaluate; this course does not provision a workflow or replace Starlight's existing orchestration owner."},{"id":"sandbox","publisher":"Vercel","title":"Sandbox","url":"https://vercel.com/docs/sandbox","use":"Isolated code execution option; verify lifecycle, network boundaries, entitlement and cost before a lab."},{"id":"gateway","publisher":"Vercel","title":"AI Gateway","url":"https://vercel.com/docs/ai-gateway","use":"Provider access and observability; model availability and spend remain account-specific."},{"id":"replay","publisher":"OpenAI","title":"Record & Replay","url":"https://learn.chatgpt.com/docs/extend/record-and-replay","use":"Computer-use workflow recording on supported macOS setups; distinct from filming a tutorial."}]}