Skip to main content

Project manifests

A project manifest is a YAML document that declares everything needed to run a cross-team initiative: identity, leadership, participating teams and external parties, milestones, component bindings, budget, autonomy, and a briefing. Project manifests are the reusable unit behind project blueprints and hand-authored projects alike — conversational tools, the visual composer, and the marketplace all write to the same shape.

The platform distinguishes two format headers:

_formatPurpose
meetloyd-projectA single project — components, milestones, participants, briefing.
meetloyd-appA full workspace bundle — one or more teams with manifests + connectors. Separate schema; see the Manifests API.

The rest of this page covers meetloyd-project. Both can be deployed through the same endpoints.

Where manifests live (BYOS)​

When your tenant has a bring-your-own-storage configuration active, project manifests live on your storage (SharePoint, Google Drive, S3, Azure Blob, or the platform-managed fallback) at canonical paths:

manifests/
├── blueprints/
│   └── {slug}.yaml
└── projects/
    └── {slug}.yaml
  • Drop a YAML at manifests/blueprints/onboarding-cohort.yaml on your drive and the platform's discovery surface picks it up automatically — you can deploy it, save it as a blueprint, or promote it to the catalog.
  • Edits from the visual composer, conversational save flows, and the REST API all round-trip through the same path.
  • Tenants without BYOS keep working: manifests continue to live in the control-plane database and migrate the first time they're edited after BYOS is configured. Running backfill-manifest-storage.ts pre-migrates every eligible row at once.

Minimal example​

_format: meetloyd-project
_version: "1.0.0"

project:
  name: Website Refonte
  slug: website-refonte
  description: Drupal 10 migration for the customer portal
  goal: Cut editor time by 40% within one quarter
  targetEndDate: "2026-09-30"

lead:
  type: user
  ref: user://alice@customer.com
  role: lead

participants:
  teams:
    - ref: team://content
      role: content
    - ref: team://frontend
      role: technical
  externals:
    - kind: external_via_epp
      ref: epp://moa@customer.com
      role: customer-contact
      verificationLevel: email

milestones:
  - id: discovery
    name: Discovery sprint
    dueDate: "2026-05-15"
    approvalRequired: true
  - id: build
    name: Build phase
    dueDate: "2026-07-30"
    dependencies:
      - discovery

components:
  - id: interview_campaign
    version: ">=1.0.0"
    invokeAt:
      milestone: discovery
      phase: before
    params:
      maxTurns: 6
      synthesize: true

context:
  briefing: |
    Existing CMS handles 2k articles, 8 editors, WCAG AA required.
    Target platform is Drupal 10 with RGAA 4.1 compliance.

autonomy:
  mode: supervised

budget:
  total:
    amount: 80000
    currency: EUR

Top-level fields​

FieldRequiredNotes
_formatyesMust be meetloyd-project.
_versionyesSemver. 1.0.0 at the time of writing.
projectyesIdentity block — see below.
lead / sponsornoLeadership references (user or agent).
participantsnoteams[] + externals[].
milestonesnoOrdered list with IDs and dependencies.
componentsnoComponent invocations bound to milestones.
contextnoShared briefing + propagation policy.
autonomynoAgent autonomy mode + escalation.
budgetnoTotal, categories, spending policy.
channelsnoOpenspace + integrations (Slack, email).
kickoffnoAuto-schedule configuration for the kickoff meeting.
reportingnoDigest schedule + recipients.
pricingnoStore-listing pricing (vendor-authored manifests).
templatenoMarketing metadata for the store.
metadatanoFree-form. Round-trips untouched.

Unknown top-level fields are preserved on round-trip — the visual composer, the YAML view, and the REST API all spread-merge updates so vendor-authored extensions (pricing, tags, etc.) survive edits made elsewhere.

project block​

project:
  name: string                 # Required. Human-readable.
  slug: string                 # Required. Lowercase, a-z0-9-, unique per tenant.
  description: string          # Short overview.
  goal: string                 # One-sentence outcome statement.
  successCriteria:             # Measurable signals.
    - metric: string
      target: number | boolean | string
      unit: string
  startDate: string            # ISO date.
  targetEndDate: string        # ISO date.
  status: planning | active | paused | completed | cancelled

Participant references​

KindRef shapeExample
internal_useruser://emailuser://alice@acme.com
external_via_eppepp://emailepp://moa@customer.com
external_agentagent://domain/slugagent://thales.com/negotiator

External agents (non-platform AI agents reached through federation) are gated by a cross-org review before the runtime will dispatch to them. The wizard pauses at a per-participant review card; a compliance reviewer attests to the scope, protocol, and billing arrangement.

Components​

A component binding declares what runs and when:

components:
  - id: interview_campaign          # Component ID from the catalog.
    version: ">=1.0.0"              # Semver constraint.
    invokeAt:
      milestone: discovery           # Which milestone to bind to.
      phase: before | after          # Fires at start or completion.
    params:                          # Free-form, validated by the component's input schema.
      maxTurns: 6
      synthesize: true

Each component defines its own input schema in the component catalog — see the component catalog reference for available component IDs and their parameters.

Autonomy & budget​

autonomy:
  mode: autonomous | supervised | manual
  autoApproved:                      # Actions agents may take without approval.
    - create_task
    - send_message
  requiresApproval:                  # Actions that block on human review.
    - send_email
    - external_api
  escalation:
    - level: 1
      to: user://alice@customer.com
      timeout: "4h"

budget:
  total:
    amount: 80000
    currency: EUR
  period: project | monthly | per-milestone
  categories:
    tokens:
      limit: 2000
      approvalAbove: 500
  spendingPolicy:
    perTransaction: 100
    dailyLimit: 500
    approvalRequired:
      aboveAmount: 200
      newMerchants: true

Round-trip guarantees​

Anything the platform produces round-trips through YAML deterministically:

  • Key ordering is preserved — fields appear in the same order you authored them; the platform does not alphabetise on save.
  • Unknown fields survive edits — the visual composer spread-merges each section, so vendor extensions (custom metadata, pricing overrides) remain intact.
  • Comments are stripped on parse — YAML comments do not round-trip through the JSON intermediate. Keep annotations outside the manifest (a sibling README or the project briefing block).

Deploying a manifest​

You can deploy a YAML-authored manifest through:

  • The store — promoted and vendor-catalog templates deploy to your tenant with one click. See Marketplace.
  • The Blueprints page — browse your drafts + the global catalog, deploy directly.
  • Agentic chat — ask your assistant to "deploy the website-refonte blueprint" and it picks up the YAML from your drive.
  • REST — POST /api/v1/blueprints/{id}/deploy — see the Manifests API.

On deploy, the platform creates the project, wires milestones + component bindings, provisions storage drives, and files any preflight tasks (missing skills, unresolved external participants) as actionable items routed to the project admin.