DEVELOPERS · MANIFEST EXAMPLES

Five Drive manifests, fully worked.

The most common Drive archetypes, with the manifest each one publishes. Annotated, copy-pasteable, valid Platform Contract v1. Find the archetype that matches your Drive, fork the manifest, change the names. The rest of this page tells you why each field is set the way it is.

Pick the archetype that matches your Drive

Most third-party Drives fall into one of these five shapes. Read the one closest to yours, then mix in fields from the others if your Drive crosses categories. None of these are exhaustive — they're the minimum a Drive of that shape needs to publish.

1 · Free utility Drive Free tier

A thin Drive that does one job — checks a list of URLs every five minutes, writes uptime + latency metrics to Merkava, emits a probe.failed event when something breaks. No paid feature, no hosted product, no app for the operator to log into. Merkava is the UI.

What's distinctive: pricing_tier: 'free', no homepage needed (everything lives in Merkava), only one event emitted. capabilities is the minimum.

{
  "schema_version": 1,
  "drive": {
    "id": "uptime-pinger",
    "name": "Uptime Pinger",
    "tagline": "Pings your URLs every 5 min. Merkava-rendered, no hosted UI.",
    "category": "Utilities",
    "motion": "intel",
    "homepage": null,
    "support_url": "https://github.com/your-org/uptime-pinger/issues",
    "icon_url": "https://uptime-pinger.example.com/icon.png",
    "pricing_tier": "free"
  },
  "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"
  },
  "capabilities": ["install", "uninstall", "metrics", "events"],
  "events_emitted": ["probe.failed"],
  "events_consumed": [],
  "contract_version": "1.0.0"
}
Why no billing in capabilities: Free Drives can omit billing logic entirely — the endpoint still exists (every Drive must implement it), but it returns {plan: 'free', amount_cents: 0} always. The capability flag tells Merkava not to expect a billable line on its dashboard.

2 · Paid productivity Drive Standard · $19/mo

Your existing SaaS speaks Platform Contract. The product has its own URL, its own users, its own billing — operators who don't run Merkava use it standalone. The Drive surface is the Merkava-mounted version.

What's distinctive: homepage points at your real product, manifest endpoint lives on a separate api. subdomain, both billing and config in capabilities so Merkava can show installation status and surface settings.

{
  "schema_version": 1,
  "drive": {
    "id": "schedlite",
    "name": "SchedLite",
    "tagline": "Calendar sync + meeting prep notes inside Merkava.",
    "category": "Productivity",
    "motion": "scale",
    "homepage": "https://schedlite.com",
    "support_url": "https://schedlite.com/support",
    "icon_url": "https://schedlite.com/icon-512.png",
    "pricing_tier": "standard"
  },
  "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"
  },
  "capabilities": ["install", "uninstall", "metrics", "events", "billing", "config"],
  "events_emitted": ["meeting.synced", "meeting.summarized"],
  "events_consumed": ["contact.created", "deal.stage_changed"],
  "config_schema": {
    "type": "object",
    "required": ["calendar_provider"],
    "properties": {
      "calendar_provider": { "type": "string", "enum": ["google", "outlook"] },
      "include_external":  { "type": "boolean", "default": true }
    }
  },
  "contract_version": "1.0.0"
}
Why both endpoints live on api.schedlite.com, not schedlite.com: Crawlers hitting schedlite.com/api/meridian/drive/manifest would 404 if your marketing site is a different deployment. Keep the Contract surface on the API subdomain alongside your real API. The homepage field is for human visitors; the manifest URL is what Merkava polls.
The events_consumed array is a contract: Merkava will fan out those events to your Drive only if you list them. Listing an event you don't actually handle wastes Merkava's outbound budget; missing one means your Drive silently misses signal.

3 · AI content Drive Pro · $39/mo

A Drive that drafts long-form content — articles, briefs, comparison pages — using Forge or its own model stack. Quillsly-class. Operators kick off jobs from Merkava; the Drive emits content.draft_ready when a draft is queued for review and content.published when an approved draft lands.

What's distinctive: rich events_emitted, an explicit quota hint so Merkava can show monthly usage to the operator, and a config_schema with voice / brand-pillar fields.

{
  "schema_version": 1,
  "drive": {
    "id": "longform-co",
    "name": "Longform Co",
    "tagline": "Pillar planning to AI-search-cited articles, end to end.",
    "category": "Content",
    "motion": "scale",
    "homepage": "https://longform.co",
    "support_url": "https://longform.co/help",
    "icon_url": "https://longform.co/icon-512.png",
    "pricing_tier": "pro"
  },
  "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"
  },
  "capabilities": ["install", "uninstall", "metrics", "events", "billing", "config", "quota"],
  "events_emitted": [
    "content.draft_ready",
    "content.draft_revised",
    "content.published",
    "content.archived"
  ],
  "events_consumed": ["brand.voice_updated", "competitor.move", "knowledge.entity_added"],
  "config_schema": {
    "type": "object",
    "required": ["brand_voice", "monthly_article_quota"],
    "properties": {
      "brand_voice": { "type": "string", "minLength": 10 },
      "monthly_article_quota": { "type": "integer", "minimum": 1, "maximum": 200 },
      "publish_targets": {
        "type": "array",
        "items": { "type": "string", "enum": ["webster", "wordpress", "ghost", "github_pr"] },
        "default": ["webster"]
      }
    }
  },
  "quota": {
    "unit": "articles_per_month",
    "limit": 50,
    "overage_policy": "block"
  },
  "contract_version": "1.0.0"
}
The quota block is a soft reservation, not Merkava's billing system. Merkava bills the operator the flat tier price; the quota tells the Merkava's gauges how to render usage so the operator can self-regulate. Set overage_policy: 'block' if your Drive can't gracefully handle going over (most can't), or 'meter' if you can charge usage upstream out of band.

4 · SaaS-mounted Drive Premium · $79/mo

A Drive that ships a scoped artifact the operator deploys outside Merkava — a chat widget on their marketing site, an embedded form, a tracking pixel. Install returns a scoped_token the operator drops into a script tag. Relay is the canonical example.

What's distinctive: install_returns declares the artifact shape, install_capabilities includes provision_widget, and the manifest carries an embed_snippet template Merkava renders for the operator to copy.

{
  "schema_version": 1,
  "drive": {
    "id": "ribbon-bar",
    "name": "Ribbon Bar",
    "tagline": "A site-wide announcement bar with platform-side scheduling.",
    "category": "Marketing",
    "motion": "scale",
    "homepage": "https://ribbonbar.com",
    "support_url": "https://ribbonbar.com/support",
    "icon_url": "https://ribbonbar.com/icon-512.png",
    "pricing_tier": "premium"
  },
  "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"
  },
  "capabilities": ["install", "uninstall", "metrics", "events", "billing", "config", "provision_widget"],
  "events_emitted": ["ribbon.shown", "ribbon.clicked", "ribbon.dismissed"],
  "events_consumed": ["campaign.launched"],
  "install_returns": {
    "type": "scoped_widget_token",
    "token_prefix": "rb_pub_",
    "embed_snippet": "",
    "host_origin": "https://cdn.ribbonbar.com"
  },
  "contract_version": "1.0.0"
}
Token rotation is your responsibility. If a tenant's scoped_token leaks, your Drive's revocation flow runs through DELETE /api/meridian/install/:id — Merkava emits the uninstall, you invalidate the token, the operator re-installs to get a fresh one. Build the rotation path on day one or you'll regret it on day 30.

5 · Enterprise compliance Drive Flagship · $149/mo

A Drive that handles regulated data — PHI/PII classification, BAA-gated vendor access, access-audit ledger. Redline-class. Operators on regulated tiers expect this Drive to declare its compliance posture in the manifest so the Merkava's pre-connect gate knows whether to allow the install.

What's distinctive: a top-level compliance block (the only archetype that needs one), data_classes declaring what regulated data the Drive touches, and an SLA-bearing support structure so enterprise operators see who they can call.

{
  "schema_version": 1,
  "drive": {
    "id": "sentinel-phi",
    "name": "Sentinel PHI",
    "tagline": "PHI/PII classification + BAA registry + access audit.",
    "category": "Compliance",
    "motion": "intel",
    "homepage": "https://sentinelphi.com",
    "support_url": "https://sentinelphi.com/enterprise-support",
    "icon_url": "https://sentinelphi.com/icon-512.png",
    "pricing_tier": "flagship"
  },
  "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"
  },
  "capabilities": ["install", "uninstall", "metrics", "events", "billing", "config", "phi_handling", "audit_export"],
  "events_emitted": ["classification.flagged", "baa.expiring", "access.audit_entry"],
  "events_consumed": ["contact.created", "deal.stage_changed", "knowledge.entity_added"],
  "compliance": {
    "frameworks": ["HIPAA", "SOC2-Type-II"],
    "data_classes": ["PHI", "PII"],
    "data_residency": ["us-east-1", "us-west-2"],
    "subprocessors_url": "https://sentinelphi.com/subprocessors",
    "baa_required": true,
    "encryption_at_rest": "AES-256",
    "encryption_in_transit": "TLS 1.3"
  },
  "support": {
    "sla_response_business_hours": "1h",
    "sla_response_off_hours":      "4h",
    "incident_email":              "[email protected]",
    "status_page":                 "https://status.sentinelphi.com"
  },
  "contract_version": "1.0.0"
}
The pre-connect gate. When an operator on a regulated tier tries to install your Drive, Merkava reads the compliance block and surfaces a confirmation flow ("Sentinel PHI handles PHI under HIPAA — confirm BAA is on file"). If baa_required: true and the operator's tenant has no BAA on file, the install is blocked. Lying in this block is fraud, not a bug.
QUESTIONS

Manifest examples — questions, plainly answered.

Which archetype should I start from?

Match the closest shape to what you're building. Free utility = single-purpose, no-state, no scopes. Paid productivity = read-write integration with one external service. AI content = drafts/edits content using operator data, writes back. SaaS-mounted = your existing standalone product also exposed inside Merkava. Enterprise compliance = strict scoping, audit logging, BAA-ready. Copy the closest and edit.

Are these manifests valid against Platform Contract v1?

Yes — all five validate cleanly against the v1 manifest schema. Each example includes the required identity block, contract_version, capabilities, events emitted/consumed, scopes, and pricing tier. Run them through the manifest validator before publishing your own; the Drive Author spec documents the schema in full.

What's the minimum manifest for a free Drive?

Identity (id, name, version, category), contract_version=1, a single capability declaration, and an empty scopes array. The "free utility" archetype is the canonical minimum — about 30 lines of JSON. Free Drives don't need pricing or quota fields. Paid Drives add tier, optional quota hints, and scopes scoped to what they actually need.

How do I know which scopes to request?

Minimum needed for the use case. Operators see and approve scopes at install — broad scopes get rejected during review, and broad scopes that ship anyway get the Drive removed if we audit and find scope-creep. The compliance archetype is the strictest pattern: declare exactly which contact, deal, employee, or knowledge fields you read/write; no wildcard scopes.

Can I have multiple Drives sharing one manifest?

No. One Drive, one manifest, one set of scopes, one signing key. If your product covers multiple distinct capabilities, publish them as separate Drives so operators can install just what they need. The SaaS-mounted archetype is a single Drive representing the whole standalone product, not a slice.

How do I version a manifest?

Bump the version field on each manifest publish. Adding events, fields, or capabilities is non-breaking. Removing or changing existing event shapes is breaking and requires a Platform Contract version bump (currently v1). Operator's installed instance keeps the version they installed; manifest version bumps trigger an in-app upgrade prompt with the diff.

What's next