Field manual / 05 capabilities Educational draft Sources checked 2026-10-03

PointCast · UES · IndustryNext

Small tools. Clear authority.

A field guide to plugins, extensions, discovery, events and hosting — with practical applications for PointCast, University of El Segundo and IndustryNext.

Start with the practical recommendations

Before the tools

Build from evidence.

Start with one useful outcome. Package a repeatable method as a skill; add MCP when it needs live data or controlled actions; add an interface when seeing and choosing improves the work. Introduce ongoing monitoring only after the single-run workflow is reliable.

This is an educational draft by Codex, prompted by Mike’s three screenshots. Product claims were checked against official OpenAI documentation. Proposed prompts and outputs below are design examples, not connected services or completed work. The screenshots themselves are not reproduced.

First choice: keep the existing websites and test three read-only workflows. PointCast can produce a public evidence brief, UES can help a learner choose a course, and IndustryNext can turn supplied research into a bounded project brief.

01 / Ground truth

What exists today

Existing surfaces are the starting point for these ideas.

PointCast

Implemented and verified

Public data and a real MCP handler

Source at the recorded main commit and public read-only probes verify a real POST JSON-RPC server at /api/mcp-v2, an alias of /api/mcp. Live initialize returned pointcast-v2 2.7.0 and protocol 2025-06-18; tools/list returned 90 tools, resources/list returned 22 resources, and blocks_recent/apps_list read calls succeeded. GET serves HTML discovery. No UI metadata or ui:// resources were returned; server/discover and events/list returned method-not-found. Native extensions and MCP Events need additional implementation.

University of El Segundo

Implemented and verified

Open courses, local private progress

The public /ues/classes.json responded HTTP 200 on the check date. Its participation contract says self-paced access, no account or wallet, local browser progress and private self-attested completion receipts. Source separates progress from identity and learner artifacts. A proposed ChatGPT companion must preserve the learner’s choice about sharing notes; local progress does not automatically become model context.

IndustryNext

Implemented and verified

A public studio with proposed lab briefs

The public www.industrynext.xyz homepage responded HTTP 200 on the check date. It presents a magazine, laboratory and work table, an AI + MCP Atlas, and a Communications Lab marked proposed with applications closed. These are website surfaces, not evidence of an installed ChatGPT extension or event subscription. Its canonical repository is mhoydich/nouns5.4, with a separate release process from PointCast.

Repository baseline 2a3e35326beffc23884b8fcca1c045623fe6565b · review the source date before treating a capability as current.

02 / First moves

A useful place to begin

Choose one small, reviewable pilot for each context.

PointCast

Public Evidence Brief

Read a bounded public record and return its source URL, checked time and uncertainty. A pilot should allow only blocks_recent, block_read, blocks_search, apps_list and connector_links, with each handler reviewed; do not expose the full server catalog or rely on read-only annotations alone.
University of El Segundo

Course Companion

Match a learner’s time and interests to public course IDs. Keep progress and notes local; only share an explicitly selected excerpt when the learner requests feedback.
IndustryNext

Brief Review Desk

Use supplied research to draft an outcome, scope, assumptions and acceptance check. A human owns the release and any invitation to collaborators.

03 / The field guide

Five different moves

Each capability answers a different question. Start with the job a person needs to do.

Showing all 15 examples.

Capability 01

Plugin Extensions

Does the task improve when people can see and choose?

Extensions connect an MCP App to ChatGPT surfaces such as sidebar apps, conversation panels, file viewers and rich forms. The official examples include Canva sidebar tabs, Figma composer mentions and Adobe file handlers. An ordinary webpage or embedded dashboard is an analogy until the MCP tool, registered UI resource and extension metadata work in the target host.

Use it when

Use for comparing records, selecting an object, reviewing a visual artifact or keeping a focused workspace beside a conversation.

Avoid it when

Skip custom UI for a simple answer or short list. Avoid a large dashboard that hides the actual decision, a viewer that claims unsupported formats, or a screen that depends on drag-only input.

How the pieces fit

Build and test a focused MCP read tool with stable record IDs and structured results.
Register an MCP App UI resource; attach the supported entrypoint metadata to the tool.
Render a minimal view. Share only the selected item/context the task needs, and keep a text response usable without the panel.

Practices that make it work

Authority and privacy: Keep tokens and private notes out of UI props and model context. Enforce account/resource access on the server. Set narrow CSP origins; a UI allowlist is not backend authorization. Preview an edit and require the intended confirmation before any consequential action.
State and errors: Use stable selection IDs and versioned UI resources. Distinguish loading, empty, permission denied, offline and stale data. Preserve a recoverable selection, show its checked time, and offer a source link.
Acceptance test: Check keyboard selection, visible focus, screen-reader labels and status announcements, 390px layout, zoom, reduced motion and text fallback. Test malicious record text as data. Verify the chosen item in both panel and tool response.

Three applications

Read-only scenarios / no install or execution

PointCast

Proposed

Signal comparison panel

Compare two public Blocks or field signals with source links and age. Existing website cards are the design analogy; a native conversation panel would be new.

Example request

Compare these two public PointCast records. Show evidence, checked time and what remains uncertain.

Expected output: Two source cards and a short comparison; no publishing or changes to a room.
First small step: Prototype from two public fixtures, then validate a registered thread UI resource in a permitted test account.

University of El Segundo

Proposed

One lesson beside the conversation

Show a public module, its access alternative and a selectable rubric. Feedback uses only the excerpt a learner deliberately supplies. Browser progress stays in the course website.

Example request

Open the public Living Archive lesson and help me check this excerpt against its rubric.

Expected output: Lesson links, a rubric and feedback on the supplied excerpt; no attendance or credential claim.
First small step: Use the public catalog and a synthetic note. Verify that notes are not sent merely by opening the panel.

IndustryNext

Proposed

Brief review panel

Present scope, evidence, missing inputs and acceptance checks next to a discussion. The Communications Lab’s website briefs are an analogy, not installed extensions.

Example request

Review this supplied project brief. Show what is evidenced, what is assumed and the smallest testable proof.

Expected output: A review card with traceable evidence and a human decision point.
First small step: Use a fictional brief and text fallback before connecting any project system.

ts / illustration

Adapted metadata illustration only. server registration, imports and the UI resource still need implementation; this does not create an extension.

const metadata = {
  ui: { resourceUri: "ui://pointcast/evidence" },
  "openai/ui": {
    entrypoints: [{ type: "thread" }]
  }
};
// Attach as _meta to a registered MCP App tool.
// The tool must return useful structured/text data too.

Documentation: Plugin Extensions

Back to the five capabilities

Capability 02

Plugins, skills and MCP

Which parts of the method should travel together?

A plugin packages skills, MCP connections or both under a stable identity. A skill carries a repeatable method and supporting resources. An MCP server supplies actual tools and optional UI. Plugin Creator scaffolds a package; an empty configuration is not a running service.

Use it when

Use a skill for an evidence or review workflow that repeats. Add MCP when the work needs live data, authenticated records or a controlled action. Keep each first version focused on one recognizable outcome.

Avoid it when

Avoid bundling unrelated brands into one broad permission surface, undisclosed local dependencies, credentials in a ZIP, or write tools merely because a workflow might need them later.

How the pieces fit

Write the input/output contract and one worked fixture first; version the instructions and source ledger.
For a portable package, use root plugin.json, skills/ and optional mcp.json. OpenAI metadata goes under extensions.com.openai; .codex-plugin/plugin.json remains supported as a fallback.
Test locally/private first. A public release adds identity/domain verification, automated scans and human review; publication is a separate decision.

Practices that make it work

Least privilege: Start with supplied or public material. A plugin installation is separate from app authorization. Private access needs the relevant consent and OAuth implementation, with issuer, audience, expiry and scopes checked on every call. A model-supplied user ID never grants access.
Contracts and failure: Use narrow tool names, constrained input/output schemas and accurate read-only/destructive/open-world hints. Validate server-side. Return stable IDs, source URLs, checked times and explicit missing-data errors. Proposed writes need idempotency keys and conflict/version checks; retries must not duplicate changes.
Reviewable release: Test familiar, incomplete, adversarial and out-of-scope inputs and text fallback. The current MCP submission guide asks for five positive and three negative cases, a walkthrough and release notes; sign-in reviewers use a dedicated sample account. Approval precedes Publish. Recheck current submission rules before release.

Three applications

Read-only scenarios / no install or execution

PointCast

Analogy

Package the visiting method

The existing /for-agents handbook and scoped JSON/MCP surfaces already separate etiquette from capabilities. A Public Evidence Brief skill could package the reading method. It would still need a separately tested plugin connection.

Example request

Using only these public PointCast sources, draft an evidence brief with links, checked time and gaps.

Expected output: Evidence / observations / uncertainties / suggested next check.
First small step: Write one skill against saved public fixtures; do not inherit the full existing MCP write catalog by default.

University of El Segundo

Proposed

Field Observation skill

Turn one public lesson into a private practice plan with a seated or remote equivalent, source note and self-check. A skill can do this from supplied curriculum without a learner account.

Example request

Turn this UES lesson into a 20-minute practice with a remote alternative. Do not imply verified completion.

Expected output: Practice, materials, access alternative, evidence note and a private self-check.
First small step: Use public course IDs and one synthetic example; keep the output independent of completion storage.

IndustryNext

Proposed

Research-to-Brief skill

Package a method for naming the question, evidence, assumptions, owner role and acceptance criteria. Source accounts and any recruitment remain separate choices.

Example request

Make a bounded project brief from this supplied research. Mark missing facts and name the review role.

Expected output: Question / evidence / one-week proof / exclusions / acceptance / unresolved inputs.
First small step: Test three fictional briefs, including one without enough evidence. Do not invent a collaborator or partnership.

text / illustration

Illustrative portable package layout. It is a plan for files, not an installed plugin or MCP endpoint.

public-evidence/
  plugin.json
  skills/
    evidence-brief/
      SKILL.md
      references/example.md
  mcp.json  # optional; references a separately built server

Documentation: Package your plugin

Back to the five capabilities

Capability 03

Discovery and helpful selection

Will the right tool activate for the right request?

Tool names, descriptions and schemas help ChatGPT choose an appropriate capability. Better metadata and measured task usefulness are concrete work. The fetched official guidance does not establish a ranking algorithm or guarantee directory placement, recommendations or traffic.

Use it when

Use explicit names and descriptions when people can express the same goal in several ways. Build a labeled prompt set before tuning metadata.

Avoid it when

Avoid claims that publishing guarantees recommendations, keyword stuffing, inflated capabilities, deceptive branding or broad descriptions that cause false activations.

How the pieces fit

Choose a domain/action name and state when the tool is useful and when it should not run.
Expose bounded arguments and accurate safety hints; return user-openable evidence links rather than promotional copy.
Run direct, indirect and negative prompts. Record selected tools, arguments and results; change one metadata field and repeat.

Practices that make it work

Measure usefulness: Track correct selection, false activation, grounded answers, task completion and fallback. Prioritize negative-prompt precision. Evaluate old prompts again after a schema, description, model or host change.
Keep recommendations honest: Explain why a tool fits and disclose material limitations or commercial ties. A recommendation is not permission to install, link an account or widen scope. Treat stale metadata and unavailable tools as states that need clear alternatives.
Make the result accessible: Use plain titles and text summaries that remain clear without artwork or a panel. Version the prompt set, date the source snapshot and keep logs free of private prompt text where it is unnecessary.

Three applications

Read-only scenarios / no install or execution

PointCast

Analogy

A legible public tool catalog

PointCast already exposes app and connector catalogs. That is an analogy for discoverable capabilities. A future public-record tool should be specific about reading evidence and should reject requests to publish or change wallet state.

Example request

What public evidence supports this PointCast signal?

Expected output: Expected future tool: pointcast_get_public_record. Negative: “Publish a dispatch” must not call the read tool as a write substitute.
First small step: Test direct “read Block…” and indirect “what changed?” prompts against negative wallet/publication prompts.

University of El Segundo

Proposed

Course selection with honest boundaries

Describe a public-course search tool as finding lessons by topic and time. Do not market it as an enrollment, grading or accredited certification service.

Example request

I have 20 minutes and want to learn local observation. Which public UES lesson fits?

Expected output: A public course/module link and an access alternative; negative certification requests receive an explanation.
First small step: Test “pick a class”, vague interests, no-match interests and “certify my degree”.

IndustryNext

Proposed

A brief tool with a clear job

Name the capability as reviewing supplied briefs, and distinguish it from hiring, buying services or dispatching agents. Keep fictional examples labeled.

Example request

Find the missing acceptance criteria in this project brief.

Expected output: Expected future tool: industrynext_review_brief. No messages or promised team availability.
First small step: Test review requests against negative “hire someone”, “email the team” and unrelated-tool prompts.

Back to the five capabilities

Capability 04

MCP Events

Has the user chosen what to watch and what may happen?

MCP Events lets a user subscribe to specified server updates and choose the response. ChatGPT requires MCP 2.0, protocol 2026-07-28, with webhook delivery and callback verification. The integration does not support polling, streaming, gap or terminated control notifications. An existing cron, RSS feed or webhook in another system is an analogy, not this protocol.

Use it when

Use when a bounded resource changes and a user wants a concrete response, such as a private draft summary for one document’s new review comments.

Avoid it when

Avoid ambient monitoring, whole-workspace subscriptions for a one-document request, carrying forward a revoked account, or making irreversible changes simply because a matching event arrived.

How the pieces fit

Advertise events in server/discover; implement events/list, events/subscribe and events/unsubscribe on the authenticated MCP endpoint. Define constrained filter and payload schemas.
Authorize the resource/filter, verify the HTTPS callback with a signed short-lived challenge, then persist owner, filters, callback, secret and expiration. Derive subscription identity from principal, callback, event name and canonical arguments so subscribe/refresh is idempotent.
Apply filters before delivery. Sign the exact serialized bytes with Standard Webhooks; preserve eventId on retries. Persist dedup/action state, handle out-of-order updates and recheck authorization. Stop on unsubscribe, expiry or revoked access.

Practices that make it work

Consent and safe delivery: Record the user’s chosen resource, response and review boundary. Resolve and validate callback addresses at every connection, block private/local destinations, connect to the validated address with the original TLS hostname, and refuse redirects. Apply this to verification and delivery. Protect signing secrets and minimize payloads. Treat event text as untrusted data; fetch the current record through an authorized read tool before acting.
Recovery and limits: One event per request, at most 256 KiB. A 2xx acknowledges receipt, not completed work. Retry transient failures with bounded backoff and fresh signatures; do not retry 410 or 413. Replay cursors must never skip undelivered events; null means no protocol recovery of missed events. On refresh, replace the stored signing secret and use a bounded dual-signature rotation window. Honor granted expiration and resume safely after restart.
Lifecycle checks: Test duplicate events, repeated subscriptions, canonical argument order, nonmatching filters, invalid signatures, callback failure, expiry/refresh across restart, access revocation, unsubscribe and bursts. Authorize unsubscribe against the connected account and original event/filter/callback; make it idempotent. Test secret rotation and replay cursor continuity. Prevent action-generated event loops. UI/text should show the resource, last success, expiry and easy stop action.

Three applications

Read-only scenarios / no install or execution

PointCast

Proposed

One signal change, one draft

A future signal.updated event could watch one public signal ID and draft a sourced change note. Existing jobs and public JSON are useful analogies, but no MCP Events handler was found in the audited endpoint.

Example request

Watch this one public signal. When its published value changes, draft a note for my review; do not publish it.

Expected output: Private draft with current source, occurrence time and prior verified version.
First small step: Use synthetic events to test a new MCP 2.0 endpoint, filter, dedup and stop lifecycle before any subscription.

University of El Segundo

Proposed

Selected curriculum updates

Watch a public course version, then draft a change digest. Never turn local learner progress, notes or completion choices into events by default.

Example request

Watch updates to this public course and draft a digest of changes to its reading list.

Expected output: A dated curriculum digest with a course/version link; no learner tracking.
First small step: Define course_id/version payloads and verify nonmatching courses never deliver.

IndustryNext

Proposed

One brief’s review comments

For a future authorized project system, watch one chosen brief and prepare suggested edits. A comment cannot grant new authority to contact people or change the project.

Example request

Watch review comments on this brief and prepare proposed edits for my review.

Expected output: A proposed diff linked to the authorized current brief; no external message or automatic release.
First small step: Test with a dedicated synthetic tenant, revoke access mid-subscription, and verify both delivery and future actions stop.

json / illustration

Proposed events/list event definition, adapted from the official schema. This declares a contract; discovery, auth, subscription storage, signing and delivery are not implemented here.

{
  "name": "signal.updated",
  "description": "A selected public signal changed.",
  "delivery": ["webhook"],
  "inputSchema": {
    "type": "object",
    "properties": {"signal_id": {"type": "string"}},
    "required": ["signal_id"],
    "additionalProperties": false
  },
  "payloadSchema": {
    "type": "object",
    "properties": {
      "signal_id": {"type": "string"},
      "version": {"type": "integer"},
      "source_url": {"type": "string"}
    },
    "required": ["signal_id", "version", "source_url"],
    "additionalProperties": false
  }
}

Documentation: MCP Events

Back to the five capabilities

Capability 05

Sites and hosting choices

Which host fits the actual runtime and access model?

Sites can host compatible websites and web apps. The verified documentation also describes workspace-private Sites with connected plugins, visitor-selected accounts and consent. The narrower screenshot claim that a Site can host an MCP server or extension was not established by the permitted documentation fetched for this guide; verify that capability and runtime in the actual account before planning around it.

Use it when

Consider Sites for a small new companion, private prototype or compatible project with an appropriate access model. Treat hosting the website, operating an MCP endpoint and registering a ChatGPT extension as separate implementation responsibilities.

Avoid it when

Avoid moving PointCast simply to match an announcement, assuming Cloudflare bindings transfer automatically, exposing owner credentials to visitors, or treating a Sites deployment URL as a private preview.

How the pieces fit

Inventory routes, Cloudflare Pages functions, Workers, KV/D1/R2, scheduled jobs, streaming behavior and secrets. Map each dependency and consent boundary before choosing a host.
Compare keeping the existing host, hosting a separate companion, or migrating a compatible subset. Validate auth, persistence, network behavior, source identity, logs and rollback in a saved version.
Review the concrete version before deployment. Sites deployment URLs are production; save without deploying for review. Retain the current PointCast main/deploy lane until a migration is separately approved.

Practices that make it work

Visitor boundaries: For connected data, verify workspace-private eligibility and enabled permissions. Each visitor selects their own connections and consents; never substitute the owner’s account. Private data and write actions need server authorization, clear action controls and the intended review/confirmation.
Operations: Define persistence, retention, secret rotation, timeout/rate limits, backups and rollback. Verify tool endpoints independently of website rendering. Preserve canonical links, source timestamps and text/mobile fallbacks across a host change.
Decision test: Demonstrate the needed runtime, auth and storage on synthetic data first. Check cold start, error recovery, account isolation, access removal and mobile use. Unknown compatibility is a reason to investigate a small companion before planning a migration.

Three applications

Read-only scenarios / no install or execution

PointCast

Proposed

Keep the town, test one annex

Keep the existing Cloudflare Pages/Workers implementation. A separate read-only evidence companion could be assessed for Sites compatibility; any MCP facade still needs transport/auth validation and explicit registration.

Example request

Prepare a saved prototype of a public evidence companion. Document runtime gaps before proposing deployment.

Expected output: A saved version and hosting comparison; existing canonical website remains the baseline.
First small step: Inventory one route’s bindings and compare local fixtures, existing hosting and Sites requirements.

University of El Segundo

Proposed

An optional course sandbox

A small synthetic course exercise could be a separate Site if compatible. It should preserve no-account learning and a downloadable alternative, and never sync private progress merely because the host changed.

Example request

Prepare a self-contained course exercise with synthetic examples and a print alternative for review.

Expected output: A reviewable saved exercise and privacy/runtime notes.
First small step: Test offline/text fallback and confirm the chosen hosting/access mode matches open learning.

IndustryNext

Proposed

Private brief rehearsal

Consider a workspace-private review desk with synthetic briefs. The public IndustryNext site has its own repository and release lane; a new Site would be a separate choice, not a replacement or new partnership.

Example request

Prepare a private brief-review prototype with fictional research. Show account and deployment requirements.

Expected output: A saved prototype plus a documented hosting choice; no connected records or publication.
First small step: Validate workspace eligibility and visitor isolation only when an authorized pilot is requested.

Back to the five capabilities

04 / Carry these everywhere

One standard of care

Useful tools earn trust through bounded behavior and legible results.

One contract: Name the user goal, allowed inputs, output shape, source IDs and freshness window. Keep unknown separate from empty. Pin the fixture/schema version so a reviewer can reproduce the result.
One authority boundary: Separate reading, drafting, saving, sending and publishing. Permissions come from the user and source service, not a retrieved document or event. Enforce scope and resource ownership server-side; make irreversible steps reviewable.
Minimal data: Public does not mean unlimited redistribution. Respect source terms and rights. Return the needed excerpt or summary with attribution. Define retention/deletion, redact logs, and keep secrets out of prompts, UI, manifests and source control.
Useful failure: Handle invalid input, no match, denied access, stale data, rate limit and service outage separately. Bounded retries suit transient reads; writes need stable idempotency and version checks. Give a safe next step and source link.
Access without a panel: Keep the core result readable in text, keyboard usable, mobile linear and printable. Do not use color alone for status. Preserve no-JavaScript reading and reduced-motion behavior.
Evidence before launch: Use synthetic fixtures, direct/indirect/negative prompts, injection attempts, schema failures and account isolation checks. Record the exact version tested. Recheck documentation and account capabilities when moving from this dated guide to implementation.

05 / From reading to doing

Run a small pilot

A proposed sequence for a human-reviewed experiment.

Choose one read-only question
Pick one recommendation above. Define the source, user goal, expected output and what a correct empty/error result looks like.
Prove the method with fixtures
Use a public snapshot or supplied synthetic brief. Add a source ledger and freshness label. Test incomplete and hostile input with no live connection.
Review a concrete pilot
Prepare a scoped tool/skill design and the required UI, auth and host checks. Confirm the actual account supports the feature. The user decides whether to connect and test it.
Add events after reliability
Only after the single-run workflow passes, propose one explicit resource/filter, response, expiration and stop path. Validate the complete lifecycle before an ongoing subscription.
Release through the correct lane
Submit the guide and any pilot design for editorial review and human publication approval. Plugin installation, account connection, public directory publication and website deployment each need their own concrete review.

06 / Reading desk

Sources & limits

Follow the evidence. Product availability and documentation can change.

Plugin Extensions
Fetched 2026-10-03; entrypoints, metadata examples, partner examples and surface availability.
Package your plugin
Fetched 2026-10-03; portable structure, compatibility scaffold and distribution boundaries.
Build plugins
Fetched 2026-10-03; private workflow creation, testing and separate app access.
Upload and submit your plugin
Fetched 2026-10-03; scans, reviewer cases, current MCP limits and separate publication.
Optimize metadata
Fetched 2026-10-03; golden prompt sets, tool selection and measurement. No rank guarantee established.
MCP Events
Fetched 2026-10-03; MCP 2.0 webhook lifecycle, signing, auth, replay and limitations. The protocol is a draft integration.
Sites
Fetched 2026-10-03; hosting, beta limits, saved versions, visitor data and access controls.
DevDay 2026
Fetched 2026-10-03; announcement context. Feature-specific documentation carries the implementation detail.
Build an MCP server
Fetched 2026-10-03; focused tools, structured output, annotations, transport and test/deploy requirements.
Authenticate users
Fetched 2026-10-03; token validation, per-tool auth and account identity boundaries.
Security and privacy
Fetched 2026-10-03; consent, least privilege, prompt injection, CSP, retention and authorization.

What this draft can establish

No ChatGPT plugin installation, native extension, event subscription, new credential, connected private app or directory publication was performed or verified for these three brands.
Live PointCast initialize, tool/resource discovery and two public read calls were verified on the check date. This is not a complete audit of all 90 tools, authentication paths, transport conformance or an installed ChatGPT plugin. An annotation/handler consistency correction is recorded in the draft review notes.
UES and IndustryNext public GET checks establish the documented public content at the check time, not future availability, private integrations, participant engagement or partnerships.
The Sites-hosted MCP/extension claim remains unverified within the three allowed official documentation domains. Review runtime/account support before implementing that proposal.
Additional UES and IndustryNext studies have separate review and publication decisions. This guide links only verified public destinations.
This page’s brand filter only changes which proposed examples are visible. It performs no tool calls, subscriptions, storage or external actions. Examples and code are educational illustrations.

Build from evidence.

What exists today

Public data and a real MCP handler

Open courses, local private progress

A public studio with proposed lab briefs

A useful place to begin

Public Evidence Brief

Course Companion

Brief Review Desk

Five different moves

Use it when

Avoid it when

How the pieces fit

Practices that make it work

Three applications

Signal comparison panel

One lesson beside the conversation

Brief review panel

Use it when

Avoid it when

How the pieces fit

Practices that make it work

Three applications

Package the visiting method

Field Observation skill

Research-to-Brief skill

Use it when

Avoid it when

How the pieces fit

Practices that make it work

Three applications

A legible public tool catalog

Course selection with honest boundaries

A brief tool with a clear job

Use it when

Avoid it when

How the pieces fit

Practices that make it work

Three applications

One signal change, one draft

Selected curriculum updates

One brief’s review comments

Use it when

Avoid it when

How the pieces fit

Practices that make it work

Three applications

Keep the town, test one annex

An optional course sandbox

Private brief rehearsal

One standard of care

Run a small pilot

Choose one read-only question

Prove the method with fixtures

Review a concrete pilot

Add events after reliability

Release through the correct lane

Sources & limits