RESOURCES · DRIVE MANIFEST REFERENCE

Drive manifest reference

Every Drive publishes a JSON manifest at /api/meridian/drive/manifest. This page documents every field — required, optional, and the conditional shapes (compliance, install_returns, quota) — with type, validation rules, and a worked example each. Pair with the examples gallery for end-to-end manifests by Drive archetype.

Live reference: api.quillsly.com/api/meridian/drive/manifest — Quillsly is the canonical first-party manifest.

The shape, top-down

Every manifest is a JSON object with this skeleton. required means the validator rejects the manifest if absent. optional defaults to "feature off."

{
  "schema_version":     1,                    // required
  "drive": { ... },                           // required (identity block)
  "endpoints": { ... },                       // required (the 7 paths)
  "capabilities":       [ ... ],              // required
  "events_emitted":     [ ... ],              // required (may be empty)
  "events_consumed":    [ ... ],              // required (may be empty)
  "contract_version":   "1.0.0",              // required

  "config_schema":      { ... },              // optional · JSON Schema
  "quota":              { ... },              // optional · usage hint
  "compliance":         { ... },              // optional · regulated-tier gate
  "support":            { ... },              // optional · enterprise SLA
  "install_returns":    { ... }               // optional · for SaaS-mounted Drives
}

Required fields

schema_version

number · required · always 1 for v1 of the contract

Pinned to the integer 1 for the current Platform Contract. When the contract bumps to a backwards-incompatible v2, this becomes 2; old Drives keep working at v1 until they re-publish. Don't use a string ("1") — must be a JSON number.

drive

object · required · identity block

Everything the Garage needs to render the listing card + the operator needs to identify your Drive. Required keys:

  • id · string · lowercase-hyphen slug · stable forever (pinned to install records, payouts, slug reservations)
  • name · string · operator-facing display name
  • tagline · string · ≤ 80 chars; what the operator sees on the card
  • category · string · one of Productivity, Sales, Content, Operations, Intelligence, Marketing, Compliance, Utilities
  • motion · string · one of build, scale, intel · drives in-platform grouping
  • homepage · string · public-facing product URL · null for Merkava-only Drives
  • support_url · string · where operator support tickets route (your responsibility, not Merkava's)
  • support_email · string · same purpose · email contact
  • icon_url · string · 512×512 PNG/SVG, served over HTTPS
  • pricing_tier · string · one of free, starter, standard, pro, premium, flagship

endpoints

object · required · the 7 paths

Path strings (not full URLs) for the seven Platform Contract endpoints. Merkava prepends the base of the manifest URL.

"endpoints": {
  "health":    "/api/meridian/health",
  "manifest":  "/api/meridian/drive/manifest",
  "metrics":   "/api/meridian/metrics",
  "events":    "/api/meridian/events",
  "billing":   "/api/meridian/billing",
  "install":   "/api/meridian/install",
  "uninstall": "/api/meridian/install/:id"
}

Paths can vary if you have your own routing scheme, but each must be reachable on the same origin as the manifest URL. :id is the only path-parameter convention; substitute when calling.

capabilities

array of string · required

Declare every capability the Drive supports. Merkava hides UI for capabilities you don't list (e.g., no quota dial if you don't list quota).

Standard values:

  • install, uninstall · the install handshake (essentially always present)
  • metrics, events · expose data back to Merkava's substrate
  • billing · paid Drives only · enables billing-summary surfaces in Merkava
  • config · operator-set fields exist · Merkava will surface a config form (see config_schema below)
  • quota · usage caps per tenant · pairs with the optional quota top-level block
  • provision_widget · returns a scoped artifact at install (see install_returns)
  • phi_handling, audit_export · regulated-tier extras · pairs with the compliance block

events_emitted

array of string · required (may be empty)

Event-type strings the Drive emits to Merkava's platform event bus. The Merkava's automation matrix surfaces these for operator opt-in. Naming convention is noun.verb in past tense (install.created, content.published, baa.expiring). Listing an event you don't actually emit is a lie that breaks operator-side automation.

events_consumed

array of string · required (may be empty)

Event-type strings the Drive listens for from Merkava. This is a contract — Merkava only fans out the events you list, and only verifies your endpoint can receive each one at install time. Listing an event you don't actually handle wastes outbound budget on Merkava's side; missing one means your Drive silently misses signal.

contract_version

string · required · semver

The Platform Contract version this Drive implements. Currently "1.0.0". Tracks Merkava's contract semver (not your Drive's product version — that goes in drive.version if you choose to publish it).

Optional fields

Add only the blocks you actually use. Each is "feature off" if absent.

config_schema

JSON Schema · pairs with "config" in capabilities

A standard JSON Schema describing operator-set config fields. Merkava auto-renders a form from this schema at install time + on the Drive's settings panel. Only type: 'object' top-level is supported; nested objects fine.

"config_schema": {
  "type": "object",
  "required": ["brand_voice"],
  "properties": {
    "brand_voice":  { "type": "string", "minLength": 10 },
    "monthly_quota": { "type": "integer", "minimum": 1, "maximum": 200 }
  }
}

quota

object · pairs with "quota" in capabilities

Tells the Merkava's gauges what unit to render. Reservation, not billing — Merkava bills the flat tier price; the quota is for operator self-regulation.

  • unit · string · the unit you meter (articles_per_month, installs_per_month, api_calls_per_day)
  • limit · integer · the cap
  • overage_policy · string · block (Drive returns 402 over the cap) or meter (Drive bills usage upstream out of band)

compliance

object · required for regulated-tier installs

Drives the Merkava's pre-connect gate for tenants on regulated tiers (HIPAA, SOC2, PCI). Lying in this block is fraud, not a bug — every claim must be substantiated.

  • frameworks · array of string · e.g. ["HIPAA", "SOC2-Type-II"]
  • data_classes · array of string · e.g. ["PHI", "PII"]
  • data_residency · array of string · region codes (us-east-1, etc.)
  • subprocessors_url · string · public list of subprocessors; emits subprocessor.updated when changed
  • baa_required · boolean · if true, Merkava blocks installs without a BAA on file
  • encryption_at_rest · string · e.g. AES-256
  • encryption_in_transit · string · e.g. TLS 1.3

support

object · enterprise SLA hints

Surfaces SLA + contact info on the listing page for enterprise operators evaluating the Drive. Doesn't change Merkava's behavior — purely informational.

  • sla_response_business_hours · string · e.g. 1h
  • sla_response_off_hours · string · e.g. 4h
  • incident_email · string · paged on Sev-1
  • status_page · string · public uptime URL

install_returns

object · pairs with "provision_widget" in capabilities

For Drives that ship a deployable artifact (chat widget, embed, tracking pixel). Tells Merkava how to render the install response so the operator can copy the snippet.

  • type · string · usually scoped_widget_token
  • token_prefix · string · token namespace (rb_pub_)
  • embed_snippet · string · template with {{scoped_token}} placeholder
  • host_origin · string · the CDN/host the embed loads from

Validating

Two paths, same validator under the hood:

Apply for developer access →
QUESTIONS

Drive manifest — questions, plainly answered.

What is a Drive manifest?

A JSON document that every Merkava Drive publishes describing its identity, capabilities, and how it talks to Merkava Core. The manifest declares ID, name, version, category, events emitted, events accepted, config schema, and pricing/quota hints. Live example at api.quillsly.com/api/meridian/drive/manifest.

What does a manifest actually declare?

Five things: (1) Drive identity — ID, name, version, category. (2) Events emitted — what the Drive sends to Core. (3) Events accepted — what the Drive can receive from Core. (4) Config schema — what Merkava asks the operator to provide at install. (5) Pricing + quota hints — so Core can meter fairly across tenants.

Where is the manifest hosted?

On the Drive's own infrastructure, served at a stable URL. Quillsly serves its manifest at api.quillsly.com/api/meridian/drive/manifest. Merkava Core fetches it at install time and re-validates on version bumps. Self-hosting the manifest means the Drive controls its own publish cadence — no central registry to wait on.

What event format does the manifest use?

Each event is typed with required and optional fields, similar to a JSON Schema declaration. Core validates inbound and outbound events against the manifest before delivery. Arbitrary payloads are explicitly rejected — typed events are the contract that lets Drive-to-Drive composition work without webhooks.

Can I update a manifest after publishing?

Yes — bump the version field and Core picks up the new manifest on next sync. Adding events, fields, or config options is non-breaking. Removing or changing existing event shapes is breaking and triggers the standard deprecation runway: ship the new version, mark the old fields deprecated, give one full Platform Contract version before removing.

How does pricing get communicated through the manifest?

The manifest declares the Drive's pricing tier (one of the six standard tiers or "custom"). Core surfaces the tier in the Garage listing and on the operator's invoice. Per-event quota hints let Core soft-throttle high-volume Drives before the operator hits their tier ceiling.

Do I need a manifest for a private Drive (single-tenant, internal)?

Yes — even private Drives speak the Platform Contract, so they publish a manifest. Private Drives just don't list in the public Garage. The manifest still defines events, config, and signing keys; the only difference is discoverability.