What are the core architecture components?
The core system includes the Presenton application and workers, corporate identity, language and image providers, presentation storage, a database or task state, observability, and optional internal integrations.
Document the flow of uploaded files, extracted text, prompts, generated assets, presentation objects, and final exports. Mark which component stores each artifact and which network boundary each request crosses.
Keep interactive UI traffic and service-to-service API traffic separately identifiable. Service workloads should use scoped credentials and quotas rather than sharing user sessions.
How does a private model endpoint fit?
Presenton sends generation requests to the configured provider, which can be a public service, Azure OpenAI, Ollama, or an OpenAI-compatible endpoint depending on the deployment.
A private endpoint architecture keeps network routing under enterprise control while using managed model infrastructure. A local-model architecture keeps inference internal but adds GPU capacity, model serving, monitoring, and upgrade responsibilities.
Model output should pass through validation before rendering and human review before important external delivery. Private routing reduces exposure; it does not make model output automatically correct.
How should automated applications connect?
Internal applications should call a protected presentation API through an approved gateway, submit validated content or source files, track asynchronous jobs, and retrieve scoped outputs for review or delivery.
CRM, reporting, analytics, and workflow systems can generate branded decks without exposing Presenton directly to the public internet. Add request validation, idempotency, rate limits, audit context, and workload identity.
Store source references, template version, model configuration, generation job, and final output together so a deck can be reproduced and investigated.
What the platform supports
Enterprise capabilities
Corporate identity
Place user access behind the selected SSO and authorization design.
Private model routing
Connect approved cloud, private, or local AI endpoints.
Internal storage
Store sources, assets, and generated files according to policy.
API gateway
Protect service generation with workload identity, quotas, and monitoring.
Asynchronous workers
Isolate longer generation jobs from interactive application requests.
Observability
Monitor availability and cost without logging unnecessary sensitive content.
Decision matrix
Architecture decision matrix
Select the smallest architecture that satisfies the data and operational requirements.
| Architecture | Data boundary | Operational effort | Primary use |
|---|---|---|---|
| Managed cloud | Managed service | Low | Fast enterprise pilot |
| Customer VPC + private endpoint | Customer cloud and approved model route | Medium | Private cloud adoption |
| Fully private | Customer infrastructure | High | Sensitive or sovereign workloads |
| Air-gapped | Isolated environment | Highest | No outbound connectivity |
| Internal API platform | Depends on hosting model | Medium to high | Automated business applications |
Reference patterns
Deployment architecture patterns
Deployment A — fully private
Nothing requires leaving customer infrastructure when all dependencies are internal.
Deployment B — customer VPC
The customer controls application, network path, credentials, and storage.
Deployment C — API automation
Internal systems generate governed presentations through service credentials.
From evaluation to production
Architecture design sequence
- Step 01
Define trust boundaries
Classify data and identify permitted processing and storage locations.
- Step 02
Select providers
Choose model, image, search, database, storage, and identity components.
- Step 03
Design operations
Plan capacity, queues, observability, backups, recovery, and upgrades.
- Step 04
Prove the system
Test security, throughput, failure handling, editability, and business approval.
Evaluation checklist
Questions to resolve before rollout
- Context and data-flow diagram
- Component ownership
- Network routes and private endpoints
- Secrets and certificate management
- Queue and concurrency model
- Storage lifecycle
- Monitoring and recovery
- Non-production validation environment
Buyer questions
Frequently asked questions
Can Presenton connect to Azure OpenAI through a private endpoint?+
Presenton supports Azure OpenAI configuration. The private networking route, DNS, identity, and endpoint policy are implemented in the customer environment and should be validated during deployment.
Can internal applications generate presentations?+
Yes. Applications can call the presentation API to generate and export decks. Protect the API with approved authentication, validation, quotas, and audit context.
Does the architecture support local models?+
Yes. Ollama and OpenAI-compatible endpoints are supported options. Local operation also requires internal image and other supporting services for a fully private workflow.
What outputs can the architecture produce?+
Presenton supports editable PPTX and PDF workflows, with additional output options in documented API editions. Confirm the exact API version and environment.
Primary references
Product capabilities and enterprise terms can change. Confirm current edition, deployment, security, support, and contractual details with Presenton before making a purchasing decision.
