Builder

What Builder Does

Builder is the interface through which Experts translate their domain expertise into governed execution tools. It generates the six ABI contract files that define each app — without the Expert needing to write or edit JSON directly.

🗂️

Design workflows

Define the ordered steps the system must perform for your professional task.

📥

Configure inputs

Specify every piece of data the user must supply — type, label, validation, and whether required.

📤

Define outputs

Declare the exact structure of every field in the result the platform will deliver.

⚙️

Set governance signals

Configure supervision requirements, risk level, engine binding, and governance profile.

🧪

Test execution

Run your workflow against test inputs and verify output structure before publishing.

🚀

Publish tools

Accept the Digital Oath and submit your app to Appstream for review and publication.

Building Your App: Step by Step

Every app you build in Builder follows a structured authoring sequence. Each step produces part of the final ABI contract.

Step 1

info.json

Define Your App Identity

Give your app a name, description, version, category, jurisdiction, and tags. This is what users see in Appstream when browsing or searching. The description must be accurate — stating what the app produces, not just what it does.

Rule: Descriptions must not overstate accuracy or claim outputs are certified or definitive. Include professional caveats where required.

Step 2

input.json

Configure Your Input Fields

Define every field the user must provide before execution. For each field, specify:

Field label and description (clear, professional language)
Data type: text, number, date, boolean, file, select
Validation rules: minimum/maximum length, required/optional
Accepted file formats (if file upload is used)

Rule: Only collect data your workflow actually needs. Collecting data beyond what is declared violates the platform's data governance policy.

Step 3

preset.json

Define the Execution Structure

Specify how the platform should organise the inputs and execution context when processing your app. The preset defines the structural template the platform uses to understand the execution.

Rule: Steps must be ordered, each step must have clear input/output, and no hidden transformations are permitted.

Step 4

result.json

Declare the Output Schema

Define the exact structure of every field, section, and sub-field the system must produce. This is a binding contract — the platform validates every execution output against result.json before delivering it to the user. Outputs that do not conform are discarded and not charged.

All required output sections and fields
Data types for every field
Length constraints where relevant
Professional caveats and limitation disclosures

Rule: Incomplete or open-ended schemas are rejected in review. Every output field must be declared. Vague schemas indicate the workflow is not sufficiently defined.

Step 5

meta.json

Set Execution Metadata

Configure the execution metadata that identifies your app and sets its runtime parameters:

engine_binding — which Primary Engine the app is authorised to use (must be on the platform allow-list)
execution_mode — Direct, Customise, or Discovery
version — the version identifier for this app release
Provider selection settings — how the platform should choose the appropriate service for this app

Rule: Engine bindings must be on the platform allow-list. Bindings not on the list are rejected at review.

Step 6

governance.json

Set Governance Rules

Define the governance rules and constraints that control how the platform enforces your app at execution time:

supervision_required — true for legal, financial, and regulatory outputs; false only for low-risk factual tasks
risk_level — LOW, MEDIUM, HIGH, or CRITICAL (determines approval path)
governance_profile — the named governance profile that sets enforcement rules
jurisdiction — applicable jurisdiction context

Rule: supervision_required: true is mandatory for any app that produces outputs which affect a user's legal, financial, or professional position.

Pipeline Design Rules

A pipeline is the ordered set of steps your workflow executes. Every pipeline you design must follow strict structural rules. The platform enforces these rules at execution time.

Valid Pipeline

Input → Parse → Analyse → Validate → Output

Steps are ordered
Each step has clear input and output
No hidden logic between steps
Transformations are explicit

Invalid Pipeline

Unclear step boundaries
Mixed responsibilities in a single step
Hidden transformations
Ambiguous step outputs
Steps with no declared purpose

Using Engines

Engines are pre-built execution units provided by the platform. Experts do not create engines — they declare which engine their app is authorised to use via the engine_binding field in meta.json. The platform selects the appropriate execution path at runtime.

Write

Produces structured professional documents: memos, reports, letters, briefs

Analyse

Processes and interprets documents, contracts, or datasets

Summarise

Produces structured summaries of documents or information

Audit

Reviews documents or processes against defined criteria

Verify

Checks facts, references, and claims against external authority sources

Compare

Produces structured comparisons between documents, versions, or datasets

Calculate

Performs structured numerical and financial calculations

Guide

Produces step-by-step process guidance and professional checklists

Rule: Use only approved engines from the platform allow-list. Do not assume engine behaviour beyond what is declared. The platform determines execution routing — Experts have no access to these decisions.

External Data in Workflows

Some apps may draw on external authoritative sources — government databases, regulatory registers, legal precedent repositories, or enterprise data systems. This is configured at the governance profile level, not directly by the Expert.

Data is controlled and audited

All external data used in execution is accessed through the platform's controlled provider layer. Experts cannot configure direct data connections. Platform governance controls all external data access.

You must define how it is used

Where your app incorporates external data, your workflow definition must explicitly specify what the data is used for and how it influences the output. Undeclared data use is a governance violation.

Outputs must reflect correct interpretation

The Expert is responsible for ensuring external data is used correctly and that the output correctly reflects what the data says. Platform governance verifies data provenance, not data interpretation.