Skip to content
Tredy

Authoring a service

Download
This page (Markdown) Full docs (Markdown) Full docs (PDF) Full docs (Word)

You don’t build a Tredy service by wiring stages by hand. You describe the outcome, and Tredy’s Service Designer assembles a governed, runnable definition from a proven playbook — then you refine it in an editor.

How it works

  1. Describe it in plain English. Write a one-paragraph description of the outcome you want.

  2. Tredy picks a playbook. Your description is matched (lexically, then semantically) to a best-practice playbook — competitor intelligence, coverage / policy / security-control / regulatory / contract / vendor gap analysis, document analysis or comparison, regulatory monitoring, denials prevention. The playbook brings a proven tool chain, quality gates, and a deliverable format. Cross-cutting best-practice skills are always attached.

  3. The model drafts, code assembles. An LLM proposes the inputs, agents, and stages; Tredy deterministically expands that into a strict service definition and overlays the playbook’s governance. Only read-only capabilities are freely selectable — anything that exports or publishes is reachable only through an approval-gated stage, never freehand.

  4. Auto-lint, grade, and accept. The draft is linted, graded by a reviewer model, and put through a deterministic acceptance gate (required capabilities, quality gates, review gates, deliverable sections). Tredy self-corrects up to twice, keeping a revision only if it genuinely improves.

  5. Refine in the Service Creator. The result opens in the editor for you to adjust — nothing is persisted until you save.

Lifecycle & governance

Once you save, a service moves through a maker–checker lifecycle, fully audited at every step:

draft → validated → submitted → approved → published → installed

Publishing hot-registers the service with zero runtime changes, and every definition change is recorded with a hash for provenance.