01

Your Augmented Studio

Your studio is augmented by your team, their community creations, and AI -- embedded into your enterprise's infrastructure, security, and legal environment.

A living, auditable record of what has been built and why
Designed for leadership review, ICT audit, and public reference
Institution-generic by design -- applicable to any education or research organisation
Some implementation specifics are intentionally redacted in accordance with institutional security policy
May 2026
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
02

Executive Snapshot

What exists, what works, and why it matters

6 frontend application surfaces serving distinct user workflows
4 backend API services handling AI, conversion, and analysis
3 dedicated databases plus a shared platform data layer
Dual-environment deployment: internal institutional host and external public server
Role-based access control across 5 permission levels
Multi-provider AI integration with user-owned and admin-managed keys
6Frontend Apps
4API Services
3+1Databases
2Environments
5Access Levels
NAI Providers
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
03

Strategy Alignment

How the platform embodies the studio.ai vision

Describe it: users explain what they need in natural language
It just works: the platform builds, hosts, and secures it automatically
Share it: publish to your team or the wider community
Monetise it: charge via internal cost centres or public Stripe payments
Open-source foundation: the approach is transferable and auditable
Institutional-grade: runs inside your compliance boundary, not outside it
1Describe it→
2It just works→
3Share it→
4Monetise it
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
04

Platform Top Layer

What users see and interact with

Main portal: tools, navigation, settings, and API key management
AI chat: configurable bot builder with multi-provider support
Translation: purpose-built interface for translation workflows
Documentation: structured content browser for learning materials
Administration: operational dashboard for teaching and assessment data
Each surface is a self-contained application with shared authentication
studio / chat
How can I analyse these survey results?
I can help you build a pipeline that extracts themes from open-ended responses...
Type a message...↑
studio / translate
Source (EN)
The methodology section should describe the research design...
Target (DE)
Der Methodenteil sollte das Forschungsdesign beschreiben...
studio / docs
Getting Started
API Reference
Tutorials
Getting Started
studio / admin
NameStatusScore
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
05

Middle and Back End

Services, contracts, and ownership boundaries

Frontend containers orchestrate; backend services execute
Each service owns one responsibility and one data domain
Integration contracts define how components interact
Identity and access: shared Supabase auth across all surfaces
Document conversion: isolated backend with format-specific pipelines
AI execution: provider-agnostic routing with user-owned keys
Frontend
web
chat
translate
docs
admin
tools
↓ auth + API calls ↓
Services
AI routing
doc-converter
readability
phonetics
↓ queries + RLS ↓
Data
supabase (auth + platform)
db-phonetics
db-teaching
db-assessments
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
06

Deployment Topology

From development to production across three tiers

Local device: development, testing, and rapid iteration
Institutional host: internal deployment behind organisational network
External server: public-facing production environment
Coolify: container orchestration and deployment management
Mirrored environments ensure parity between internal and external
Automated health checks and smoke tests validate each deployment
DEV
Local Device
Development and testing
→
INT
Institutional Host
Internal deployment
→
EXT
External Server
Public production
CoolifyContainer orchestration · builds · health checks
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
07

Security and Auditability

Defense-in-depth across transport, application, and data layers

Transport: HSTS with preload, strict referrer policy, DNS prefetch control
Application: CSP with self-only scripts, no frames, no external connections
Access: 5-level permission model with middleware route gating
Data: row-level security policies in PostgreSQL via Supabase
Signup: invite-gated registration with bot protection
Governance: retention policy, consent framework, audit intent
Transport
HSTS (2yr, preload)Strict referrerNo DNS prefetch
Application
CSP: self-only scriptsNo frames / no embedNo external fetch
Access
5-level role modelMiddleware route gatingInvite-only signup
Data
Row-level securityEncrypted at restScoped sessions
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
08

API and Tools Inventory

Services available to platform applications and users

AI chat: multi-provider streaming with model selection and parameter control
Document conversion: markdown, PDF, DOCX, PPTX, HTML, email parsing
Readability analysis: Flesch-Kincaid scoring with detailed metrics
Web scraping: structured content extraction from public pages
Bot management: CRUD operations for configurable AI assistants
Key management: encrypted user API keys with provider-specific resolution
AI Chat
POST /chat (streaming SSE)GET /models
Next.js API routes
Doc Conversion
POST /convertPOST /jobsGET /jobs/:id
FastAPI + Pandoc
Readability
POST /analyzeGET /health
FastAPI
Key Management
GET/POST/DELETE /keysresolve(user>admin)
Supabase + encryption
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
09

Programming Concepts Applied

Key patterns and why they were chosen

Server-Sent Events (SSE): real-time AI response streaming without WebSocket complexity
Row-Level Security (RLS): database-enforced access control independent of application logic
Role-based middleware: server-side route gating before any page or API logic executes
Provider key resolution: layered credential lookup from user to team to platform level
Monorepo task graph: Turborepo orchestrates builds, tests, and lints across all packages
Multi-target Docker: single Dockerfile builds any application via build arguments
Async job queues: long-running conversions run asynchronously with polling status
BYO key architecture: users control their own AI spend and provider choice
Server-Sent EventsUnidirectional AI streaming without WebSocket complexity
Row-Level SecurityDatabase-enforced access -- apps cannot bypass
Role MiddlewareServer-side route gating before page logic runs
Key ResolutionUser then team then platform fallback hierarchy
Monorepo + TurborepoConsistent builds with dependency-aware caching
Multi-target DockerOne Dockerfile, any app -- via build arguments
Async Job QueuesLong conversions run without blocking requests
BYO Key ArchitectureUsers own their AI spend and provider choice
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
10

Build Your Own

Isolated artifact creation with platform-aware AI assistance

Users describe what they need; the platform builds and deploys it
AI coding agents operate within an isolated building environment
Agents are parameterised with platform knowledge: available APIs, auth patterns, deployment targets
Artifacts inherit platform security, hosting, and access control automatically
Created tools can be shared, published, or monetised immediately
No coding expertise required -- but full code access available for those who want it
1
User describes need
↓
2
AI agent builds in isolated environment
↓
3
Artifact inherits platform security + hosting
↓
4
Share, publish, or monetise
conceptualplatform-aware agent context
// the agent receives platform parameters
agent.context = {
  availableAPIs: [...],
  authPatterns: { supabase, rls, middleware },
  deployTargets: { internal, external },
  sharedComponents: [...],
  securityConstraints: { ... }
}
// artifacts fit the platform immediately
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
11

Institutional System ConnectorsUnder Development

Bridging siloed systems without vendor cooperation

Direct API connectors: interface with systems that expose endpoints
Output-processing adapters: parse export formats that existing systems already produce
Target systems: resource planning, student records, event management, learning management, assessment
Enormous organisational value: bridge data silos without requiring vendor changes
Each connector is a governed, auditable integration point
Modular: connectors can be built incrementally by different teams
Mode A: Direct API
Source System API↔Platform Connector→Platform Tools
Mode B: Output Processing
System Export (CSV/PDF)→Parse + Normalise→Platform Tools
Resource PlanningStudent RecordsEvent ManagementLearning ManagementAssessment
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
12

Roadmap and Gaps

Transparent status of what is complete, in progress, and planned

Complete: authentication, role model, AI chat, document conversion, readability tools, dual-environment deployment
Complete: API key management, bot builder, multi-provider support, health monitoring
In progress: calibration workflows for assessment quality assurance
In progress: course document publishing pipeline
Planned: institutional system connectors and output-processing adapters
Planned: full self-service artifact creation workflow with AI assistance
Complete
Auth + role modelAI chat + multi-providerDoc conversion pipelineReadability toolsDual-env deploymentBot builderKey managementHealth monitoring
In Progress
Calibration workflowsCourse publishingPresentation pipeline
Planned
System connectorsSelf-service artifact creationSSO integration
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.
13

Get Involved

Engagement paths for every context

Use it: explore the platform, build tools for your own workflows, provide feedback
Evaluate it: review the architecture and security posture for your context
Adapt it: the approach is open-source and institution-generic -- take what works, modify what doesn't
Collaborate: propose integrations, contribute connectors, share what you build
Support it: invest in development capacity to accelerate the roadmap
This document is a living reference -- it will be updated as the platform evolves
Use it
Explore the platform, build tools for your workflows, provide feedback
Evaluate it
Review the architecture and security posture for your context
Adapt it
Open-source and institution-generic -- take what works, modify the rest
Collaborate
Propose integrations, contribute connectors, share what you build
Support it
Invest in development capacity to accelerate the roadmap
studio.Some implementation specifics are intentionally redacted in accordance with institutional security policy.