Power should arrive
with visible boundaries.

1. Current product status

The current Boardesa AI workspace is a simulated product experience. Its responses are predefined and generated by local browser logic. Prompt text is not sent to Boardesa, an AI provider, or a hidden API. The Command Center and composer may use deterministic, in-browser keyword matching to suggest a workspace mode; that routing is not a model response and is not a correctness judgment. There are no user accounts, cloud histories, document uploads, model routing, automated grading, subscriptions, or payment processing in this version. Session exports are created only in the browser at the user’s request and may include the visible conversation, selected context, and an unsent draft. Shared workspace links deliberately exclude prompt text, context, and transcript content, and any recent-session recovery snapshot remains versioned, same-tab, time-limited browser storage that the user can restore or discard. The interface shows whether that recovery save succeeded and falls back to a browser leave-page warning only when storage protection is unavailable. The local workspace also uses a versioned request/response contract with explicit cancel, timeout, retry, and edit states. Retries retain a random per-operation identifier while receiving separate attempt identifiers. They are also bound to the original mode, response style, prompt, and context through a deterministic SHA-256 digest over a versioned canonical payload. Malformed Unicode is first converted to a well-formed string, Unicode is normalised to NFC, line endings are standardised, context is deduplicated and stably ordered, and the canonical JSON is hashed as UTF-8. A future server adapter must reproduce that process, verify the digest, and still apply authentication and authorization; this remains frontend lifecycle design rather than a live model or safety guarantee.

That limitation is intentional. Connecting a model is technically easier than building a responsible system around it. A public education product needs cost controls, abuse protection, privacy choices, quality evaluation, age-aware design, incident handling, and clear user expectations before live processing begins. The interface can be polished first, but its safety claims must not run ahead of its actual infrastructure.

2. Product design principles

3. Risk controls by workflow

Different education workflows fail in different ways. A single generic warning is not enough. Before launch, each live module should have a small risk model, evaluation set, and visible user controls.

4. Evaluation before and after launch

A polished interface is not evidence that a model is suitable. Boardesa should evaluate candidate providers and prompts against the actual workflows shown on this site. Testing should include normal tasks, difficult edge cases, incomplete instructions, conflicting context, adversarial requests, age-sensitive scenarios, and examples where the correct response is to ask a clarifying question or refuse.

Evaluation should measure more than whether an answer looks good. Relevant dimensions include factual accuracy, mathematical validity, instruction following, age appropriateness, bias, privacy leakage, citation behaviour, refusal quality, latency, cost, and consistency across repeated attempts. Teacher-facing outputs need separate checks for curriculum assumptions, accessibility, classroom feasibility, and answer-key reliability.

After launch, quality monitoring should distinguish product analytics from user content. Aggregate signals such as failed requests, refusal rates, latency, cost, and voluntary feedback can help improve the service without defaulting to indefinite storage of complete prompts. Material changes to models, system prompts, document processing, or safety filters should trigger renewed evaluation rather than relying on old results.

5. Education-specific safeguards

Boardesa should support legitimate learning without pretending that every institution has the same rules. Academic-integrity expectations can vary by school, university, teacher, assignment, and jurisdiction. The product should therefore help users understand, practise, outline, check, and revise while reminding them to follow the rules that apply to their work.

For younger users, the safest default is more guidance and less data collection. The product should avoid manipulative engagement patterns, public profiles, unnecessary social features, and pressure to share identifying information. A future school deployment would require role controls, administrative expectations, retention settings, and clear responsibility between Boardesa, the institution, teachers, parents or guardians, and learners.

Boardesa should not silently grade a learner, determine educational eligibility, or make high-impact decisions. If assessment-support features are introduced, they should remain transparent aids with human review, clear criteria, and a way to correct context or challenge an output.

6. Data and provider boundaries

Real AI calls must be made through protected backend infrastructure. Provider keys must never be exposed in HTML or browser JavaScript. The backend should authenticate requests where necessary, enforce rate and cost limits, validate input size and file type, strip unsupported metadata, and keep provider-specific implementation details behind a stable product interface.

Before a provider receives user content, Boardesa should document what is sent, why it is needed, whether the provider may retain it, which region may process it, and how deletion or abuse review works. Model improvement using user content should not be assumed. Any optional history or personalisation feature should have a clear benefit, a visible control, and a deletion path.

Highly sensitive information—including passwords, payment data, private student records, medical details, safeguarding reports, or confidential institutional material—should not be requested by general learning workflows. Upload features will need file validation, malware protection, retention limits, access control, and a clear explanation of extraction and model-processing steps before they become active.

7. Non-negotiable launch gates

8. Machine-readable integration contract

Before a live model is connected, frontend and backend implementations need one reproducible definition of the payload, retry lineage, idempotency namespace, and response-binding fields. Boardesa publishes a preview contract at /.well-known/boardesa-workspace-contract.json. It includes the active schema identifiers, canonicalization order, limits, idempotency format, server responsibilities, and cross-runtime SHA-256 test vectors.

The endpoint is technical documentation, not a public API promise and not a security credential. A future server must still validate every field, authenticate users where required, impose rate and cost controls, recompute the digest independently, reject the same idempotency key when paired with different canonical content, and avoid trusting client timestamps or provider labels. Contract changes that would break compatibility should receive a new schema version rather than silently changing the meaning of an existing one.

9. Accountability and change

Responsible AI is not a one-time launch label. Boardesa should keep an internal record of major model, prompt, safety, retention, and provider changes; re-test affected workflows; and update public explanations when a change materially alters how user information or generated output is handled.

Users should have a practical reporting route. A useful report identifies the workflow, what the user expected, what occurred, and a non-sensitive example. Security vulnerabilities should be reported responsibly without accessing other users’ information, disrupting the service, or publishing exploitable details before a fix is available. Machine-readable reporting instructions are available at /.well-known/security.txt.

This page describes product commitments and launch criteria; it is not a certification and does not claim that inactive future features already meet every requirement. When live AI begins, the page should be revised to describe the actual provider architecture, active safeguards, known limitations, and review date.

10. Frequently asked questions