Secure first owner
A guided first-start journey prepares the databases and creates the first System Owner through local MFA or a compatible OIDC provider.
For technical buyers
Trace the whole system before you trust the answer
A polished AI response tells you very little about the architecture behind it. With Pūnaha, you can examine where the product runs, how it retrieves knowledge, which identity and tenant rules apply, what reaches each model and how running work survives over time.
Capability view
What you can put under the microscope
| Area | Current capability | Evaluation focus |
|---|---|---|
| Deployment | Customer-controlled infrastructure; all-in-one or separate service pools; Windows and Linux builds | Network, service placement, shared storage, backup, identity and data path |
| Knowledge | Tenant-aware stores, document processing, semantic and hybrid retrieval, local or cloud-backed LanceDB destinations | Sources, permissions, relevance, retention and migration |
| Models | Local GGUF execution plus supported external model providers with separate deployment resources | Provider terms, data movement, model suitability and measured runtime fit |
| Workflows | Visual modules, versioning, schedules, events, human work, messages, evidence checkpoints and restart-aware execution | Change control, failure handling, accountability and throughput |
| Processes and cases | BPMN-based process execution, decision tables and CMMN-based adaptive cases | Model scope, external mappings and formal assurance boundary |
| Identity and access | Local sign-in, TOTP MFA, OIDC with PKCE, groups, roles, resource-level grants, denials and access reviews | Identity design, least privilege, delegation, recovery and review ownership |
| Connections | HTTP, SMTP, Microsoft 365, SQL Server, PostgreSQL and MySQL configuration with encrypted secrets | Least privilege, allow-listing, TLS, provider consent and live target validation |
| Operations | Audit history, operational logs, execution events and local, S3 or Azure Blob log destinations | Monitoring, retention, remote delivery, incident response and support ownership |
Control and access
Understand who controls the installation and each resource inside it
The installation owner, a tenant role and access to an individual workflow are different responsibilities.
Named resource access
Apply exact actions to a workflow, case, knowledge store, model deployment or connection rather than relying only on broad roles.
Review access governanceExplainable decisions
Inspect the roles, groups, grants, denials and timing behind effective access.
Delegated access management
Let an appropriate person manage access without automatically giving them permission to use the protected resource.
Formal access reviews
Record keep, change and remove decisions, with results available for export.
Service identities
Use explicit service subjects for private calls between enabled parts of the platform.
Evaluation areas
Follow the path from sign-in to operational action
Identity to source
Confirm tenant selection, role and group resolution, source access and administrative separation.
Source to retrieval
Confirm extraction, storage destination, tenant separation, relevance and the treatment of source permissions.
Retrieval to model
Understand which content reaches which local or external deployment under each workflow path.
Model to decision
Evaluate validation, content protection, human review and the handling of incomplete or unsuitable results.
Decision to operation
Review messages, integrations, retries, failure paths, execution history and operational ownership.
Change over time
Confirm immutable published versions, pinned child resources, controlled migration and restart behaviour.
Runtime and storage
Running it on your infrastructure involves more than installing it
Pūnaha packages the application services into one executable. You can run the enabled services together or place control, workflow, AI and browser-facing responsibilities in separate pools. MySQL remains a separate dependency that your operating model needs to cover.
Local GGUF models can use CPU and supported accelerated runtimes. Pūnaha records measured recommendations separately for embedding and generation workloads, while administrators retain control over the selected processing policy.
The platform uses three logical MySQL databases for control, workflow and AI concerns. Vector indexes and structured logs can use local storage, Amazon S3 or S3-compatible storage, or Azure Blob Storage. Changing a vector destination does not copy an existing index, so migration or re-ingestion must be planned.
Service boundary
Define which services run together, which are separated and who installs, patches, starts and monitors them.
Model boundary
Confirm model licensing, file provenance, hardware fit and the permitted content path.
Storage boundary
Choose shared durable data, vector and log destinations, with credentials, backup, recovery, retention and migration for each purpose.
Admission and readiness
Confirm unique node identities, approved service roles and direct readiness before an instance receives work.
Current boundaries
Here is where we draw the line today
A technical review is more useful when the current limits are stated plainly.
Pūnaha does not make a broad air-gap claim. Customer-managed deployment and local models are supported, but every network path, update mechanism, identity dependency and external connection must be assessed for the intended environment.
The product has extensive owned BPMN and CMMN implementation tests, but this site does not claim formal standards conformance or certification. Independent review and external-tool interoperability evidence remain separate release gates.
External providers
Configuration support and deterministic tests do not replace consent, credentials and live validation against the customer's chosen provider and account.
Document limits
Confirm supported formats and extraction quality. Image-only material may require a separate OCR path.
High availability
Do not infer a production topology from an entitlement label. Agree the tested architecture, failover, recovery and operational responsibilities for the release.
Suggested evaluation
A practical way to run the technical review
Describe the environment
Document infrastructure, networks, identity, data sources, storage, model services and operational owners.
Choose representative work
Include one search path and either a repeatable process or an adaptive case that reflects the intended use.
Test controls and failure paths
Exercise denied access, unsuitable content, unavailable models, failed connections, rejected human work, retries and restart.
Inspect retained evidence
Review database state, execution events, audit history, remote logs and cleanup rather than relying on the visible result alone.
Agree the implementation boundary
Record what Pūnaha provides and what remains part of the customer's surrounding platform, assurance and governance.
Questions we expect technical teams to ask
Can identity come from an enterprise provider?
Pūnaha implements OIDC authorization code flow with PKCE and supports mapped external groups. The target provider, claims, consent and recovery design still require environment-specific validation.
Are credentials returned through the settings API?
No. Configured connection and cloud-storage secrets are encrypted at rest and are not returned by the settings API.
Can services be deployed separately?
Yes. The same executable can enable all services together or selected control, workflow, AI and browser-facing service roles. The chosen topology needs shared durable storage and environment-specific acceptance testing.
Can we evaluate restart behaviour?
Yes. The automated product coverage includes restart-aware journeys for local models, knowledge, workflows and selected BPMN execution paths. A customer evaluation should repeat the relevant paths in its target architecture.
Bring the architecture diagram and the difficult questions
We can focus the demonstration on deployment, identity, retrieval, models, workflows, cases, connections and the assurance boundaries that matter in your environment.