Knowledge stores
Create tenant-aware knowledge databases and select semantic or hybrid retrieval for the intended query pattern.
For developers and configurators
Configure tenant-aware knowledge, provider-neutral model deployments and versioned workflows. Use the visual core steps or extend approved processes through developer-managed backend nodes.
Building blocks
Create tenant-aware knowledge databases and select semantic or hybrid retrieval for the intended query pattern.
Configure a supported local or external provider once, then refer to that deployment from workflow steps.
Use prompt, retrieval, model, approval and merge steps through the current visual experience.
Configure conditions, generic REST, read-only MySQL and generic web search nodes when the workflow requires them.
Arrange independent work in parallel and merge its outputs at a later stage.
Inspect workflow state, approvals and execution records while diagnosing behaviour.
Conceptual configuration
This illustrative shape shows the relationship between a retrieval step, configured model deployment and human approval. It is not a copy-and-paste API contract.
A workflow refers to named resources. That separation makes it easier to change an approved model deployment or knowledge store without rewriting the purpose of every process.
workflow: research-review
version: 3
steps:
- retrieve: policy-knowledge
- model: local-review-model
- approval: subject-matter-reviewer
- merge: approved-responseWorkflow lifecycle
Set up the knowledge store, model deployments and approved connections required by the process.
Define the workflow and validate its structure before it can be published.
Publish a specific workflow version with a clear operational boundary.
Use durable execution, approval state, logs and execution history to understand behaviour.
No. The Pūnaha public website uses generated HTML, CSS and small amounts of framework-free JavaScript. The website editor is a separate local development tool.
The current visual experience exposes prompt, retrieval, model, approval and merge steps. Conditions, REST, read-only MySQL and web search are described as developer-configured backend nodes.
Workflows refer to configured model deployments. This separates workflow intent from the provider connection and supports deliberate change.
Yes. A generic REST step can be developer-configured for approved services. Authentication, network access and service-specific safety still need implementation design.
A technical demonstration can focus on the resources, nodes and operational path your developers need to assess.