A school district drafts curriculum in a Claude.ai project space but needs a production grading helper with audit trails. Which surface choice fits?

Claude surfaces should follow workload risk and audit needs, not a single convenience UI. Using Claude.ai for curriculum drafting while putting production grading helpers on the API works because drafting can tolerate interactive project spaces, whereas grading touches student outcomes, secrets, logging, and repeatable controls that an API-integrated application can enforce. Districts can brainstorm units in Claude.ai and still route scored workflows through services with authentication, retention, and audit trails. Keeping curriculum drafting and production grading together in Claude.ai projects fails because it puts scored student work in an interactive collaboration surface without the API's authentication, logging, and repeatable controls. Extending the curriculum Claude.ai project with grading helper prompts for teachers fails because it routes production scoring through a shared collaboration surface instead of an API-backed service with audit trails and access controls. Moving curriculum drafting to the API backend and running grading helpers in Claude.ai chat fails because it reverses the fit: drafting belongs in the interactive project space, while grading belongs in the API-integrated service where audit trails and controls can be enforced. Exam caveat: "API" is not automatically compliant—districts still must implement logging, access control, and data-minimization in the grading service that calls Claude. Operational check: publish a surface map (Claude.ai = curriculum drafting; API service = production grading), store API keys in the district secret manager, and require audit logs for grading helper calls before teachers rely on the tool for scored work.