Tenet Gateway is designed to authorize backend AI operations before an approved model deployment is called, with application identity, purpose, data, model, budget, and evidence rules.
Discuss the founding programTrueMadeAI is building custom Tenet Gateway implementations for customers today through scoped founding-district engagements. Each engagement is shaped around real applications, infrastructure, policy, and operational requirements. Gateway is not yet generally available.
An AI gateway is a shared traffic layer between district applications and the AI models they call. It centralizes secure model access, credentials, request routing, budgets, and operational logging. Through its founding-district program, Tenet Gateway is designed to add district policy to that path, so schools can build chatbots and internal AI tools without rebuilding the same controls in every application.
School districts can use an AI gateway to govern applications such as parent information assistants, IT help desks, board-policy assistants, and district developer tools. Each application can have its own approved identity, knowledge scope, model route, data controls, budget, and evidence rules.
Give families source-grounded answers about enrollment, calendars, transportation, handbooks, and district procedures using documents the district approves.
Start parent-facing, then adapt the same pattern for public student resources or internal support when the right identity and permissions are in place.
Guide staff through approved troubleshooting and ticket procedures using only the knowledge sources authorized for that audience.
Return cited answers from board policies and administrative procedures without treating the open web as district authority.
Give district-built tools stable model aliases, DLP, budgets, and decision evidence without hard-coding one provider.
The starter is being developed for scoped Tenet Gateway founding-district program implementations. Use it, adapt it, or replace it. The governed route underneath it is the durable product.
District-specific implementation work can be scoped separately. The district owns its application, cloud environment, approved documents, model consumption, and relevant operational records.
One Gateway. Separate applications, identities, knowledge, policies, models, and budgets. Retrieval and source authorization remain application-owned, and protected uses require separately verified identity and authoritative access controls.
Choose a data-protection, district-knowledge, or developer scenario. Then run the trace to see how an application request is evaluated before it reaches an approved model deployment.
District staff application
Draft a family follow-up note for Quinn Zapatero. Contact quinn.z@example.invalid.
Maya Chen / counselor / verified staff token
Policy and DLP run before model inference
Gemini 2.5 Flash / district project
Draft a family follow-up note for [TENET_ROSTER_NAME_1]. Contact [TENET_EMAIL_1].
Ready to trace the request
A synthetic roster name and email are present in the application request.
The selected deployment receives typed placeholders in place of the configured values.
Tenet enforces routing to the deployment selected under the district's provider configuration.
Each Gateway build is structured around a policy decision that can be reviewed before model access.
Keys represent a specific application and scope instead of a district-wide shared secret.
An application can carry authorized context about the person on whose behalf it is operating.
Policy inputs are designed to be verifiable and versioned before use.
Alias resolution, eligibility, spend boundaries, and request limits become part of the decision.
A custom implementation can transform sensitive content and verify the exact outbound representation before sending.
Operational evidence is designed around decision facts rather than full prompt and response bodies.
We work with districts to define, build, test, and review the controls required for their scoped Gateway implementation.
Choose one or two real backend AI workflows, their owners, data classes, and current model paths.
Define how application identity, acting-person context, purpose, and district policy should combine.
Evaluate hosting boundaries, identity, networking, model providers, key management, logging, and recovery needs.
Agree on test cases, review artifacts, failure behavior, and the threshold for any production decision.
A student using an AI site and a district application calling a model are not the same event. Tenet keeps those operations separate while aligning the questions used to govern them.
Explore the shared control plane| Dimension | Tenet Edge | Tenet Gateway |
|---|---|---|
| Primary actor | Student or staff member | District application |
| Traffic path | Person to supported AI surface | Application to approved model deployment |
| Policy point | Managed browser | Gateway API |
| Status | Available now | Founding-district program |
Tenet Gateway is Tenet's governance plane for district applications that use AI in the backend. TrueMadeAI currently designs and builds scoped custom implementations with customers through founding-district engagements. It is not yet packaged as a generally available service.
An AI gateway is a shared traffic layer between district applications and the AI models they call. It centralizes secure model access, credentials, request routing, budgets, and operational logging. Through its founding-district program, Tenet Gateway is designed to add district policy to that path, so schools can build multiple AI applications without recreating the same controls inside each one.
A model router primarily directs requests to model providers. The Tenet Gateway design authorizes an AI operation against district policy first, using application identity, optional acting-person context, purpose, data boundaries, model eligibility, budget, rate, and evidence rules.
No. Gateway and Edge share a policy model but keep their execution paths separate. Gateway governs application-to-model operations, while Edge governs people using supported AI products directly on managed devices.
No. A Gateway key identifies an application, and a separately verified token may identify the acting person. Access to a particular student still requires authoritative authorization for that person, purpose, and record.
The no-training posture comes from the district's selected provider contract and deployment configuration. Tenet Gateway is designed to enforce routing to that exact approved model deployment.
A school district can use an AI gateway to govern applications such as parent information assistants, IT help desks, board-policy assistants, and district developer tools. Each application can have a separate identity, knowledge scope, model route, data controls, budget, and evidence rules. Tenet Gateway remains a founding-district program.
A parent-facing District Information Assistant reference application and self-deployment blueprint are being developed as an included starting point for scoped Tenet Gateway founding-district program implementations. District-specific cloud deployment, branding, integrations, and content setup can be scoped separately.
Bring one real backend AI workflow and the operational requirements your district would need to trust it.
