The platform

Most of this system isn’t the language model.

Everyone can buy the models. What takes years to build is everything around them. Identity, authorization, connectors, a canonical data model, narrow tools, deterministic computation, provenance and audit. That layer is Quilt.

Book a technical walkthrough Security & privacy

The stack, top to bottom

Interface

Chat, artifacts and an admin console. Web, mobile, and inside the tools staff already open.

Staff-facing

Agent gateway

Classifies intent, checks policy, assembles a restricted tool set, plans, executes, checks output. Deterministic control flow, not a free-roaming loop.

Governed

Model router

Chooses an approved model by sensitivity, complexity, latency, modality and cost. No single-vendor dependency.

Replaceable

Tool gateway

Every tool call is independently authorized, parameter-validated, tenant-scoped and logged. There’s no general-purpose query tool.

Enforced

Semantic & metric layer

One definition of chronic absenteeism, on-track, growth and proficiency. Owned by your district, used by every answer.

Deterministic

Canonical K–12 model

Ed-Fi-inspired, optimized for agentic querying. Vendors map into it. Agents never see vendor schemas.

Normalized

Connectors

OneRoster, Ed-Fi, native SIS APIs, LMS, and yes, nightly SFTP, because K–12 still runs on it.

Integrated

Identity · authorization · tenant isolation · encryption · audit · lineage · DLP · retention

Present at every layer above, not bolted on at the edge.

01 · Canonical model

One model of a student. Not one agent per vendor.

The naive approach builds a PowerSchool assistant, an Aeries assistant, an i-Ready assistant, and leaves the district to reconcile them. Quilt normalizes every source into a single canonical model first, so an answer works the same way whether your neighbor district runs Synergy or Infinite Campus.

Ed-Fi-inspired structure, tuned for the way agents actually query.
Every entity carries tenant_id, effective dates and source lineage.
Vendor quirks are absorbed by the connector, never by the model.
Adding a new district takes a mapping, not a rewrite.

Student · canonical entity

student
├── enrollment          effective_start / effective_end
├── school              org hierarchy
├── grade_level
├── sections ──► teachers
├── attendance_events
├── assignments ──► course_grades
├── assessment_results
│    ├── assessment
│    ├── domain ──► standard
│    └── score / percentile / growth
├── interventions       tier, start, dosage
├── programs            EL, SED, foster, McKinney-Vento
└── authorized_relationships
     ├── instructional
     ├── counseling
     ├── administrative
     └── guardian

02 · Connectors

It connects to what you actually run.

Anyone can demo a chat box. Making one see your district is years of connector work, including the vendors with no real API.

Tier	What it covers	Why it matters
OneRoster	Users, orgs, courses, classes, enrollments, grades, gradebook objects, resources	Standardized and widely supported. Gets a district surprisingly far in week one.
Ed-Fi	Full operational data store where a district or county has one	The richest source available, and the closest to our canonical model.
Native SIS	Aeries, PowerSchool, Infinite Campus, Synergy, Focus, Skyward	Where the real fidelity lives, attendance codes, program flags, schedule history.
Assessment	i-Ready, NWEA MAP, Illuminate, CAASPP/Smarter Balanced results, local benchmarks	Growth and domain-level mastery, joined to the right student and the right window.
LMS	Canvas, Schoology, Google Classroom, LTI 1.3 / LTI Advantage	Assignment-level signal, and a place staff already are.
Documents	Board policy, AR, LCAP, SPSA, handbooks, MTSS guidance, contracts, board packets	The knowledge half. Ingested with access control on every chunk.
SFTP & flat files	Nightly CSV, scheduled exports, the vendor with no real API	Don’t underestimate this. A great schema-mapping engine is worth more than a great demo.

03 · Two kinds of memory

Structured facts aren’t a search problem.

A common and expensive mistake is to embed a student’s grades into a vector database and hope semantic search returns the right record. It will confidently return a similar one. Quilt keeps the two paths separate on purpose.

Structured store

Postgres with row-level security. Students, enrollments, sections, staff, attendance events, grades, assessment results, standards, interventions.

Reached only through narrow, authorized tools that return typed results, never free-form SQL written by a model.

Exact
Joinable
Auditable
Row-level secured

Knowledge store

Hybrid semantic and keyword retrieval over policy, curriculum, handbooks, plans and board materials, where meaning genuinely is the right way to search.

Every chunk carries district, school, department, subject, effective date and a visibility list. Retrieval filters by permission before ranking, never after.

ACL per chunk
Effective-dated
Cited to the page
Tenant-scoped index

Never, search everything → retrieve ten chunks → ask the model whether the user should have been allowed to see them.

04 · The tool layer

The model gets narrow tools, not a database login.

Giving a language model raw query access is the single most common design error in this category. Every Quilt capability is an explicit, typed, individually authorized tool. If a tool doesn’t exist for something, the system can’t do it, no matter what anyone types into the chat box.

Each tool authorizes independently. Chaining tools can’t escalate privilege.
Parameters are validated and bound. There’s no path from chat text to a query string.
Every invocation is tenant-scoped and written to the audit log.
Sensitive tools carry an additional purpose check and, where appropriate, human approval.

Available tools · teacher session

✓ get_class_roster(section_id)
✓ get_standard_mastery(section_id, standard_ids)
✓ get_assessment_results(student_id, subject, range)
✓ get_course_performance(student_id, course_id)
✓ search_district_knowledge(query)
✓ search_public_web(query)          // via broker
✓ metric.get(metric, scope, year)

✗ get_student_profile(student_id)    // out of scope
✗ get_discipline_record(student_id)  // not authorized
✗ get_staff_evaluation(staff_id)     // not authorized
✗ run_sql(query)                     // doesn’t exist

05 · The loop

What happens between your question and your answer.

Not “user → model → whatever it decides.” A governed pipeline where the model occupies two steps and code occupies the rest.

Code deterministic Model language & reasoning

Authenticate & resolve contextWho you are, your district, your roles, your org scope, your relationships. From your IdP, not from what you typed.Code
Classify intentWhat kind of question is this, and what sensitivity class does it fall into?Model
Policy check & tool scopingThe authorization engine decides what data classes are permissible and builds a restricted tool set for this session and this request.Code
Route the modelSensitivity, complexity, latency and modality select an approved provider and model.Code
Plan and call toolsThe model requests data through the tools it was given. It can’t reach anything else.Model
Authorize again, then executeEvery individual tool call is re-checked at execution time and logged, allowed or denied.Code
Compute deterministicallyRates, growth, thresholds and counts are calculated in the metric layer using your district’s definitions.Code
SynthesizeThe model explains what the numbers say, labels facts, calculations, inferences and recommendations.Model
Output checksPrivacy, safety and citation validation. A claim without a supporting source doesn’t ship.Code
Cite, answer, auditSources attached, lineage inspectable, the whole exchange written to the security audit log.Code

06 · Model routing

Never re-procure because the models changed.

Frontier models will leapfrog each other every few months for the rest of your career. A district should never have to re-procure because its vendor bet on one lab. Quilt asks for a capability, and the router picks an approved model.

Sensitivity is a routing constraint. Not every class of data is eligible for every provider or configuration.
Cost and latency are constraints too. A classification task doesn’t need a frontier reasoning model.
Nothing upgrades blindly. A new model must pass the full eval suite (permissions, accuracy, citations, injection, bias) before it serves a single district request.

Request the capability, not the vendor

quilt.reason(
  task        = "cohort_performance_analysis",
  sensitivity = "FERPA",
  reasoning   = "high",
  latency     = "medium",
  context     = 42_190
)

# router evaluates approved providers
# → contractual posture     ✓
# → data-residency policy   ✓
# → eval scores for task    ✓
# → cost / latency envelope ✓

07 · Metric layer

Define “chronic absenteeism” once. Use it everywhere.

Two people in a district can produce two different numbers for the same metric, and both can be defensible. That isn’t a technology problem, but it becomes one the moment an AI starts inventing a calculation per question.

Quilt ships a California-standard library of metrics and lets your team override any definition. The agent never writes its own arithmetic. It calls a named metric your district has approved.

See the metric library

Metric	Owner	Status
Chronic absenteeism absent ÷ enrolled ≥ 10%, CALPADS-aligned	Ed Services	District override
On-track to graduate credits + A–G progress by grade level	Secondary Ed	District override
Assessment growth matched-cohort scale-score change	Assessment	Quilt standard
Algebra I readiness board-adopted, two independent measures	Curriculum	District override
Reclassification eligible ELPAC + local criteria	Multilingual	District override

Illustrative configuration.

08 · Time

“Who is her teacher?” is a question about a date.

K–12 data is relentlessly temporal. Enrollment changes mid-year. Schedules change at semester. Program eligibility starts and ends. Accommodations get added. A system without temporal validity will cheerfully mix this year with last and never tell you.

Every canonical entity carries effective_start, effective_end, school_year, term, source_updated_at and ingested_at. Answers state which window they used.

09 · Ontology

A district is a graph, whether you draw it or not.

A teacher teaches a section, which follows a course of study, which aligns to standards, which are measured by assessments, which feed an MTSS process, which is governed by a board policy, which was adopted on a date.

Once those relationships are explicit, questions that used to require a data request become ordinary. Which schools show unusually strong math growth relative to demographically similar sites? Why did third-grade ELA proficiency fall?

10 · Provenance

Four kinds of statement, always labeled.

Trust isn’t a tone of voice. It’s the ability to check.

Fact

Retrieved directly from a system of record, with source and pull time.

Calculation

Computed by the metric layer using a definition your district owns.

Inference

A model’s interpretation of a pattern, with the evidence listed beneath it.

Recommendation

A proposed next step grounded in your policy. Always a proposal to a person.

Unknown

Insufficient evidence. Said out loud, instead of filled in with something plausible.

Two logs, always

Security audit: user, action, resource, purpose, decision, source.
AI trace: model, tools, retrieval IDs, latency, citation quality, with PII kept out.

11 · Implementation

Boring technology, deliberately.

The interesting part of this product is the governance. Everything underneath it should be the thing your CTO already knows how to evaluate.

Identity

OIDC / SAML. Google Workspace, Microsoft Entra ID, district IdPs. SCIM provisioning.

Policy

Attribute-based access control in a dedicated authorization service. Policy as code, versioned and tested.

Data

PostgreSQL with row-level security, per-tenant schemas, tenant-scoped vector and keyword indexes.

Secrets

KMS and a managed secrets store. Credentials are injected at the tool layer and never enter a prompt.

Runtime

Durable workflow orchestration. Controlled graphs, not free-roaming autonomous loops.

Observability

OpenTelemetry with privacy-safe AI traces. Raw PII doesn’t live forever in a dashboard.

Security

WAF, DLP, SIEM, SAST/DAST, dependency scanning, independent penetration testing.

Evals

A K–12-specific suite gating every model and prompt change. Permissions, citations, injection, bias, regression.

Bring your CTO. This is the conversation we like having.

Book a technical walkthrough Read the threat model