For developers and configurators

Connect knowledge, models and workflows without hiding the moving parts

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

Compose the platform around the use case

Knowledge stores

Create tenant-aware knowledge databases and select semantic or hybrid retrieval for the intended query pattern.

Model deployments

Configure a supported local or external provider once, then refer to that deployment from workflow steps.

Visual workflow steps

Use prompt, retrieval, model, approval and merge steps through the current visual experience.

Backend workflow nodes

Configure conditions, generic REST, read-only MySQL and generic web search nodes when the workflow requires them.

Parallel execution

Arrange independent work in parallel and merge its outputs at a later stage.

Execution history

Inspect workflow state, approvals and execution records while diagnosing behaviour.

Conceptual configuration

Keep model choice separate from workflow intent

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.

Illustrative workflow configuration
workflow: research-review
version: 3
steps:
  - retrieve: policy-knowledge
  - model: local-review-model
  - approval: subject-matter-reviewer
  - merge: approved-response

Workflow lifecycle

Change deliberately and inspect the result

  1. Configure resources

    Set up the knowledge store, model deployments and approved connections required by the process.

  2. Build and validate

    Define the workflow and validate its structure before it can be published.

  3. Version and publish

    Publish a specific workflow version with a clear operational boundary.

  4. Run and inspect

    Use durable execution, approval state, logs and execution history to understand behaviour.

Developer questions

Is the public website built with a JavaScript framework?

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.

Which workflow steps are visual today?

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.

Can model providers be changed?

Workflows refer to configured model deployments. This separates workflow intent from the provider connection and supports deliberate change.

Is there a generic REST connection?

Yes. A generic REST step can be developer-configured for approved services. Authentication, network access and service-specific safety still need implementation design.

Walk through the configuration behind a real workflow

A technical demonstration can focus on the resources, nodes and operational path your developers need to assess.