Edtech

    Control AI in assessment, tutoring, and learning workflows — with hard limits, policy, and FERPA-aware tamper-evident audit on every consequential decision, before it executes.

    A student-facing chatbot drafts a response that touches a minor's identifiers. A teacher-facing workflow reaches for a model that isn't approved for student-adjacent use. One district's analytics job consumes another's quota during back-to-school. No one flagged it until the district complained.

    Keel evaluates a permit before each provider call, using the rules your team defines, and writes a tamper-evident record of every decision.


    Where Systems Break Down

    • A student chatbot drafts a reply that includes a minor's name and school; the routed provider has no student-data agreement on file
    • A model upgrade ships to a teacher-facing workflow and one district's monthly spend jumps 7× before the CSM notices
    • A nightly analytics job for one district saturates shared quota; another district's real-time tutoring degrades
    • A FERPA inquiry asks who authorized a specific AI call touching a student record — and the answer is "we have logs"
    • Finance asks for per-institution AI spend — engineering reconciles from provider invoices and tenant logs for a week

    What Stops Before the Provider Call

    Every request is evaluated at the permit seam. Unsafe, unbudgeted, or unauthorized requests don't reach the model.

    • Policy gates — provider, model, and workflow choices are checked against authored rules before dispatch; mismatches never reach the model
    • Budget enforcement per institution — per-school, per-district, and per-workflow budgets evaluated before the provider bill accrues; one institution's runaway job can't drain another's allocation
    • Throttle as a first-class outcome — HTTP 429 with Retry-After for lower-priority flows during back-to-school and testing windows
    • External attestation gate — challenge parent-consent-required or age-gated workflows until an approved reviewer, an internal approval service, or an existing customer-operated upstream control attests that execution may proceed

    Example Rules You Can Enforce

    Plain English, backed by the policy engine today.

    • "Student-facing workflows only on zero-retention providers, under a signed student-data agreement your team maintains." Deny when the workflow is student-facing and either the provider's data retention is not zero or the student-data-agreement compliance flag your team maintains on the provider is not set.
    • "Any K-12 workflow is blocked the moment it tries to route to a model outside the curated-content allowlist." Deny when the institution is K-12 and the selected model is not in the curated-content allowlist — including when the original model is unavailable and a fallback would otherwise route.
    • "Per-institution budget caps are hard caps." Deny or throttle when a district's workflow exceeds its allocated budget, regardless of other institutions' headroom.
    • "Workflows collecting personal data from minors require external attestation before execution." A challenge decision holds the request until an approved reviewer or upstream consent system attests the workflow may proceed.

    Where the Firewall Strengthens the Baseline

    The prompt firewall runs a platform-wide baseline every project inherits. Your team can add education-specific detectors on top — never weaken below the floor. Detectors are evaluated before provider dispatch; blocking matches precompute a deny outcome and are recorded in the decision details. This layer screens request content; the decision still happens at the permit.

    • Student-identifier patterns — name plus DOB plus school, IEP and 504 references, disciplinary records
    • Minor-targeted content-safety lexicons — adult, violence, self-harm
    • Special-education and confidential-record markers
    • Testing-integrity and exam-security patterns

    What the Decision Record Proves Later

    This is what your auditor will ask for. Every evaluated request produces a permit — the decision artifact that survives the conversation.

    • Permit — the unit of governance; decision, reason, rule basis, provider, model, budget state
    • Stable reason code — machine-readable codes that mean the same thing across every audit, replay, and SDK
    • Tamper-evident per-project chain — every governance event participates in a chain that makes modifications detectable on later review
    • Cryptographically signed export — Ed25519 signed, verifiable via included CLI, for FERPA review, institutional audit, or state student-privacy inquiry
    • Externally anchored checkpoint — signed chain snapshots published to storage outside the runtime, on a regular cadence
    • RFC 3161 timestamp receipt — external timestamp witness evidence from an authority Keel does not control

    Cost Now, Compliance Later

    Cost. Provider charges don't show up on the platform dashboard until the bill arrives — and with hundreds of institutional tenants, reconciling a single overage is manual work. Keel blocks unbudgeted and out-of-policy execution at the permit seam — per institution, before the provider call. When estimated cost diverges from actual cost, the usage ledger supports correction, not just reporting.

    Compliance. FERPA review, COPPA inquiry, and state student-privacy audit all ask the same question — who made this request, under what rule, using which provider and model, and why was it allowed? The permit answers it. The signed export produces it. The externally anchored checkpoints and independent timestamps let an auditor verify the record against a party Keel does not control.

    If it violates policy, it doesn't run.