top companies

{
  "id": "P14-C-001",
  "name": "E2B",
  "category": "sandbox",
  "source_url": "https://docs.e2b.dev/sandbox/persistence",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Firecracker-style sandboxes with pause/resume that preserve BOTH filesystem and memory state (running processes, loaded variables); filesystem-only pause available via keepMemory:false / keep_memory=False.",
  "runtime_profiles_supported": "Arbitrary Linux processes; long-running services can run inside but are unreachable while paused. Good for package-in-host and worker profiles; sidecar-service profile works only while running.",
  "rollback_mechanics": "Not a release system. State rollback is via resuming a prior paused sandbox/snapshot; no notion of a versioned release or traffic cutover.",
  "verification_depth": "workflow",
  "production_evidence": "First-party docs give concrete operational numbers: pause ~4s per 1 GiB RAM, resume ~1s, 24h continuous runtime cap on Pro / 1h on Hobby with the counter resetting after pause-resume. Named as a supported sandbox in the OpenAI Agents SDK (e2b.dev/blog/e2b-is-now-in-agents-sdk, secondary to the docs claim).",
  "limitations": "Paused sandboxes are retained indefinitely with NO auto-kill-after-N-days setting, so snapshot storage accrues until an explicit kill(); kill() is permanent and unresumable. Services inside a paused sandbox drop client connections and must be reconnected on resume.",
  "disposition": "top10",
  "top10_rank": 1,
  "top10_rationale": "Closest match to Actionist's mixed-shape need: a sandbox that can hold a whole donor application (its processes and in-memory state) suspended and bring it back in ~1s is what makes per-capability preview isolation affordable across heterogeneous shapes. The memory-preserving pause is the differentiator over filesystem-only competitors for donor apps with expensive warm state. The indefinite-retention-with-no-TTL behaviour is a real cost-governance obligation Actionist must own, not a defect."
}

{
  "id": "P14-C-002",
  "name": "Vercel Sandbox",
  "category": "sandbox",
  "source_url": "https://vercel.com/docs/sandbox/pricing",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Ephemeral Firecracker microVMs with per-session duration limits and persistent sandboxes; snapshots persist state across sandboxes.",
  "runtime_profiles_supported": "Node.js 22/24/26 and Python 3.13 builtin, plus arbitrary OCI images. Up to 15 open ports per sandbox, so sidecar-service and microfrontend preview profiles are viable. Explicitly NOT for continuous hosting.",
  "rollback_mechanics": "None at the sandbox layer. Snapshot restore only. Release rollback lives in the separate Vercel deployment product (see P14-C-003).",
  "verification_depth": "build",
  "production_evidence": "Pricing page carries precise, dated (last_updated 2026-08-21) quotas: max session 45 min Hobby / 24 h Pro and Enterprise; max 4/8/32 vCPU by plan at 2 GB RAM per vCPU; 32 GB ephemeral NVMe; 10 concurrent Hobby / 10,000 Pro; snapshots expire 30 days after last use by default.",
  "limitations": "Only four regions (iad1 default, sfo1, cle1, cdg1). 15 open ports is a hard ceiling. Max session duration applies per session, not per sandbox, so persistent sandbox lifetime is effectively unbounded — a cost surface, not a limit. Documented as unsuitable for a 24/7 server.",
  "disposition": "top10",
  "top10_rank": 4,
  "top10_rationale": "The most precisely documented quota surface of any sandbox reviewed, which makes it the best available reference for sizing Actionist's own runtime-profile limits (ports, vCPU, session length) rather than guessing. The explicit doc statement that sandboxes are not for permanent hosting is the clearest first-party articulation of the sandbox-vs-service boundary Actionist must draw between its preview profile and its released profile."
}

{
  "id": "P14-C-003",
  "name": "Vercel (deployments: Instant Rollback, Promote, Rolling Releases)",
  "category": "paas",
  "source_url": "https://vercel.com/docs/instant-rollback",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Every deployment is immutable and retained; Instant Rollback reroutes production traffic to a prior deployment in about a second.",
  "runtime_profiles_supported": "Package-in-host and microfrontend shapes (static + functions). Not a home for donor applications that need their own long-lived database process.",
  "rollback_mechanics": "Pointer/traffic reroute to a prior immutable deployment, ~1s. Hobby can roll back only to the immediately previous production deployment; Pro/Enterprise to any eligible one. A previously promoted deployment cannot be re-promoted — you must roll back to it instead.",
  "verification_depth": "build",
  "production_evidence": "Documented caveats read like they were written from incident experience rather than marketing: after a rollback Vercel DISABLES auto-assignment of production domains so subsequent pushes to the production branch do not silently replace the rolled-back deployment.",
  "limitations": "Critically for Actionist: the rollback restores the deployment but NOT its surrounding configuration. Environment variables are not reverted if changed in project settings, config may be stale, and cron jobs revert to the rolled-back deployment's state. This is the exact composition-completeness gap Actionist's 'exact pinned composition' requirement has to close.",
  "disposition": "top10",
  "top10_rank": 2,
  "top10_rationale": "The clearest commercial proof that image/deployment rollback and COMPOSITION rollback are different problems: Vercel reverts the artifact in ~1s but explicitly leaves env vars and config at current values. Actionist's promise to release and roll back 'an exact pinned composition' is precisely the gap this documents, so it is the single most instructive negative example in the survey. The auto-domain-assignment disable is a design pattern worth copying outright."
}

{
  "id": "P14-C-004",
  "name": "Fly.io (Machines + rollback)",
  "category": "paas",
  "source_url": "https://fly.io/docs/blueprints/rollback-guide/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Fast-booting microVMs via the Machines API; rollback is not a distinct command but a redeploy of a prior image.",
  "runtime_profiles_supported": "Strong for sidecar-service and whole-donor-application profiles: full VMs, volumes, per-machine control via the Machines REST API (api.machines.dev/v1). Suits capabilities that are entire services with their own state.",
  "rollback_mechanics": "`fly releases --image` to list prior release images, then `fly deploy --image registry.fly.io/app:deployment-XXXX` to boot the old image. `--strategy immediate` trades downtime for speed; `--max-unavailable 0.5` is the middle ground. No dedicated rollback endpoint.",
  "verification_depth": "contract",
  "production_evidence": "The first-party rollback guide is unusually candid about failure modes: it states plainly that you roll back the VM image and not the database, warns that Fly may PRUNE images not deployed recently (recommending an external registry for durable rollback targets), and tells operators to confirm recovery with fly logs/fly status/Grafana rather than trusting the deploy success message.",
  "limitations": "Rollback does not revert fly.toml, env vars, secrets, or database migrations — the redeployed old image runs against CURRENT config. Autoscaled machines from the bad release persist until autoscaling winds them down. Image retention is not guaranteed.",
  "disposition": "top10",
  "top10_rank": 3,
  "top10_rationale": "The most honest first-party account of what rollback does not cover, and the shape closest to Actionist's donor-applications-as-services profile. Its image-pruning warning is a direct, concrete threat to any 'pin the exact composition and roll back to it later' guarantee: a pinned reference is worthless if the registry garbage-collects the artifact, so Actionist must own artifact retention rather than inherit a platform's."
}

{
  "id": "P14-C-005",
  "name": "Render",
  "category": "paas",
  "source_url": "https://render.com/docs/preview-environments",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Preview environments spin up a fresh copy of a WHOLE environment — services, databases and environment groups — per pull request, defined by a Blueprint.",
  "runtime_profiles_supported": "Whole-environment previews spanning multiple services and datastores. This is the closest commercial analogue to Actionist previewing a heterogeneous composition rather than a single artifact.",
  "rollback_mechanics": "Roll back to a previous successful deploy from the service Events page; Render reuses recent build artifacts so rollback is faster than a rebuild. For Docker services the rollback re-pulls the same tag or digest.",
  "verification_depth": "contract",
  "production_evidence": "Docs specify the failure and drift modes concretely: if a deploy referenced an image by TAG, Render re-pulls latest for that tag and may get a DIFFERENT image, so digests are required for predictable rollback; if the image is gone from the registry the rollback FAILS. Rolling back does not modify environment-group values because other services may depend on them; if a group used by the target deploy was deleted, the rollback proceeds WITHOUT it.",
  "limitations": "Preview environments require Pro plan or higher and are managed via Blueprints, not projects. Previews do not copy data from existing services — seeding needs Preview Environment Initialization. Environment-group semantics mean a rollback is not a full composition rollback.",
  "disposition": "top10",
  "top10_rank": 5,
  "top10_rationale": "The only surface surveyed whose preview unit is an entire multi-service, multi-datastore environment rather than one app, which is exactly Actionist's mixed-shape preview problem. Its tag-versus-digest rollback distinction is the single most transferable technical detail found: pinning by digest rather than tag is what makes 'exact composition' actually exact. The environment-group carve-out shows even a whole-environment model leaves shared config outside the rollback boundary."
}

{
  "id": "P14-C-006",
  "name": "Netlify",
  "category": "paas",
  "source_url": "https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Atomic and immutable deploys: each deploy is a complete versioned snapshot that goes live all at once; rollback is publishing a prior deploy.",
  "runtime_profiles_supported": "Static assets plus functions and redirect rules. Package-in-host and microfrontend shapes only; no donor-application-as-service profile.",
  "rollback_mechanics": "Publish Deploy on any prior successful deploy — a pointer swap, not a rebuild, so it is effectively instantaneous. Locked deploys pin the site to the published deploy so Git-triggered production builds do not overwrite the rolled-back version.",
  "verification_depth": "build",
  "production_evidence": "The atomicity claim is specified as a behavioural guarantee rather than a slogan: nothing is served publicly until all assets, functions, redirect rules and configuration are uploaded and ready, so the site is never in a half-updated state. This is the cleanest available definition of the atomic-composition property Actionist needs.",
  "limitations": "Netlify automatically deletes errored and failed deploys after 6 months, and deploys can be manually deleted, which removes rollback targets. Locked deploys are opt-in — without them an auto-published Git deploy overwrites a rollback. Verdict on whether redirect/function config is fully covered comes from the vendor's own terminology post, which is first-party but marketing-adjacent.",
  "disposition": "top10",
  "top10_rank": 7,
  "top10_rationale": "Supplies the crispest definition of atomic release in the survey — the unit going live is the complete composition including config and routing rules, not just the code artifact — which is the property Actionist is trying to achieve across heterogeneous shapes. Its locked-deploys mechanism is the correct answer to the failure mode where a subsequent automated build silently undoes a human's rollback."
}

{
  "id": "P14-C-007",
  "name": "LaunchDarkly (Guarded Rollouts, Release Pipelines)",
  "category": "release",
  "source_url": "https://launchdarkly.com/docs[local path redacted]",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Progressively increases traffic to a variation while monitoring selected metrics, and can automatically revert the rollout when it detects a regression.",
  "runtime_profiles_supported": "Runtime-agnostic — operates on flag evaluation, not on the artifact, so it applies uniformly across package, microfrontend, sidecar and worker profiles. This shape-independence is its main structural interest.",
  "rollback_mechanics": "Automatic rollback per monitored metric when sequential testing finds a statistically significant negative impact. Rollback ALSO fires on sample ratio mismatch whether or not automatic rollback is enabled, and when the new variation was not served to enough contexts by the end of the rollout.",
  "verification_depth": "workflow",
  "production_evidence": "Regression detection is specified statistically rather than as a threshold heuristic: sequential testing on absolute difference, with relative difference explicitly no longer supported. The SRM-triggered rollback firing regardless of user configuration is a strong signal of operational maturity — the vendor overrides the customer to protect correctness.",
  "limitations": "Guarded rollouts require an Enterprise plan with the Guardian add-on (limited trial otherwise); Release Pipelines are beta and restricted to certain Enterprise/Guardian customers. Rolls back flag exposure, not the deployed composition — a flag flip cannot undo a schema migration or an infrastructure change.",
  "disposition": "top10",
  "top10_rank": 6,
  "top10_rationale": "The strongest commercial example of rollback triggered by measured outcome rather than a human noticing, which is what Actionist needs if it is to observe a released composition and roll back reliably. Because it acts at flag-evaluation time it is the one mechanism in the survey that behaves identically across all five runtime profiles. Its limit is instructive too: it defines the ceiling of what traffic-level rollback can undo."
}

{
  "id": "P14-C-008",
  "name": "Checkly",
  "category": "verification",
  "source_url": "https://www.checklyhq.com/docs/guides/playwright-testing-to-monitoring/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Monitoring-as-code: the PlaywrightCheck construct promotes existing Playwright projects or tagged specs from the repo into scheduled production monitors, running standard @playwright/test with no vendor rewrite.",
  "runtime_profiles_supported": "Runtime-agnostic — exercises the deployed surface over the network, so it verifies a composition regardless of whether a capability is a package, microfrontend or sidecar service.",
  "rollback_mechanics": "Not a rollback system. Provides the CI gate that should precede release: `npx checkly test` runs checks on Checkly infrastructure without deploying, `npx checkly deploy` on merge.",
  "verification_depth": "workflow",
  "production_evidence": "The test/monitor parity claim is mechanically grounded rather than aspirational: the same spec file in the repo serves as both the PR gate and the production monitor, so drift between what CI proved and what production watches is structurally impossible. Failure artifacts are full Playwright traces, screenshots, network requests and console logs.",
  "limitations": "Verifies observable behaviour over the network only; it cannot attribute a failure to a specific capability within a composition without the test itself being written to isolate that capability. The '32.5 million checks daily, 1,000+ customers' figure is vendor marketing (secondary), not a docs claim.",
  "disposition": "top10",
  "top10_rank": 8,
  "top10_rationale": "The only surface surveyed that closes the loop Actionist actually needs — the SAME workflow-level Playwright artifact gates the release and then monitors it in production, so 'verified a complete client workflow' and 'observed it still works' are one artifact rather than two divergent suites. That single-artifact property is the direct answer to Actionist's requirement to verify complete client workflows rather than builds."
}

{
  "id": "P14-C-009",
  "name": "PlanetScale (safe migrations / deploy requests)",
  "category": "data_migration",
  "source_url": "https://planetscale.com/docs/vitess/schema-changes/safe-migrations",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Schema changes are forced through auditable deploy requests; with schema revert enabled a deployed migration can be reverted without data loss.",
  "runtime_profiles_supported": "Data plane for donor applications that own their own schema. Directly addresses the profile that image rollback cannot cover.",
  "rollback_mechanics": "Migration applies to a ghost table with continuous data synchronisation. With schema revert enabled the OLD table is retained and data keeps synchronising for a 30-MINUTE window after the deploy request closes; reverting flips the status of the two tables, restoring the former schema.",
  "verification_depth": "contract",
  "production_evidence": "The revert is a real dual-write mechanism with a stated bound (30-minute window), not a claim of unlimited undo. DDL statements issued directly to a safe-migrations branch are automatically REJECTED, which enforces the workflow rather than merely recommending it.",
  "limitations": "The 30-minute revert window means schema rollback and artifact rollback have fundamentally different time horizons — a composition rolled back hours later cannot recover its schema this way. Disabling safe migrations forfeits deploy requests, reverts, gated deploys, and data-loss warnings. MySQL/Vitess only.",
  "disposition": "top10",
  "top10_rank": 9,
  "top10_rationale": "The only surface surveyed that makes the database half of a composition genuinely revertable, closing the gap Fly and Render both explicitly disclaim. Its 30-minute bound is the key planning fact for Actionist: because schema revert expires and artifact rollback does not, a pinned composition has two different rollback horizons and the shorter one governs. Forced deploy requests with automatic DDL rejection is the enforcement pattern to copy."
}

{
  "id": "P14-C-010",
  "name": "Cloudflare for SaaS (custom hostnames)",
  "category": "edge_tls",
  "source_url": "https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/domain-support/create-custom-hostnames/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Per-customer custom hostnames with managed certificate issuance at platform scale; Enterprise can enable wildcard, adding a *.<custom-hostname> SAN.",
  "runtime_profiles_supported": "Edge/routing layer, runtime-agnostic. Serves the subdomain-per-client release target directly.",
  "rollback_mechanics": "Not applicable — routing layer. Hostname activation and certificate issuance are documented as SEPARATE validation flows, which matters because a released composition can be reachable-but-untrusted or trusted-but-unrouted.",
  "verification_depth": "contract",
  "production_evidence": "Two certificates are issued per custom hostname in browser-compatibility-maximising chains: a primary P-256 SHA-2/ECDSA cert for ECC-capable browsers and an RSA-2048 SHA-2/RSA fallback. Documented hostname-priority conflict: a standalone Cloudflare zone takes precedence over a wildcard custom hostname even with no DNS record present.",
  "limitations": "Wildcard issuance and CA selection/custom certificate upload are ENTERPRISE-ONLY via the API. With wildcards enabled you cannot customise per-hostname TLS settings — minimum TLS version falls back to the zone setting, and cipher/TLS settings apply only to the direct hostname. Wildcard DCV needs two TXT tokens via ACME DNS-01 (apex plus wildcard).",
  "disposition": "top10",
  "top10_rank": 10,
  "top10_rationale": "The managed counterweight to the Caddy on-demand TLS prior, and the reason that prior deserves a second look rather than automatic acceptance. It demonstrates that certificate issuance and hostname routing are two independently failing subsystems, a distinction Actionist's subdomain release path must handle. The Enterprise gating on wildcards is the concrete commercial fact that decides build-versus-buy at the edge."
}

{
  "id": "P14-C-011",
  "name": "Modal (Sandboxes + Snapshots)",
  "category": "sandbox",
  "source_url": "https://modal.com/docs/guide/sandbox-snapshots",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Sandboxes for untrusted/agent code with three snapshot kinds: Filesystem Snapshots (which are Images and can seed new Sandboxes), Directory Snapshots, and preview Memory Snapshots.",
  "runtime_profiles_supported": "Worker and scheduled-job profiles are the natural fit. Directory Snapshots allow mounting one sandbox's directory into another independently of the base image, which is an interesting primitive for composing capabilities from separately-built parts.",
  "rollback_mechanics": "State restore from a Filesystem Snapshot; not a release rollback mechanism.",
  "verification_depth": "build",
  "production_evidence": "Docs state limitations rather than hiding them: snapshotting currently TERMINATES the sandbox (flagged as a limitation Modal intends to remove), a sandbox cannot be snapshotted while a Sandbox.exec is running, background processes launched via exec are not properly restored, and open TCP connections are closed on snapshot.",
  "limitations": "Memory Snapshots are early preview, expire 7 days after creation with no extension, and can only be restored on the SAME exact instance type. Sandboxes with snapshot enabled or restored from snapshots cannot use GPUs. Filesystem Snapshots default to a 30-day TTL as of v1.5 Python / v0.8.0 Go+JS. On VM Sandboxes (beta) only Filesystem Snapshots work.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-012",
  "name": "Cloudflare Sandbox SDK",
  "category": "sandbox",
  "source_url": "https://developers.cloudflare.com/sandbox/concepts/containers/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Isolated Linux containers on Workers + Containers, backed by Durable Object bindings, with SDK APIs to execute code, manage files, run background processes and expose services.",
  "runtime_profiles_supported": "Sidecar-service and worker profiles; exposing services from a Worker is a documented first-class capability, which suits microfrontend and service previews behind the same edge.",
  "rollback_mechanics": "unknown — not documented as a release/rollback surface on the pages reviewed.",
  "verification_depth": "build",
  "production_evidence": "Concrete operational constraints are documented: container image, instance type and resource limits are declared in wrangler.jsonc; multiple Ubuntu-based image variants are published (cloudflare/sandbox:0.7.0 default lean, -python, -opencode); extending the base image must NOT override ENTRYPOINT.",
  "limitations": "Port 3000 is reserved by the SDK's internal Bun server and cannot be exposed, so dev servers must be moved. The stable @cloudflare/sandbox package and the @cloudflare/sandbox@next 1.0 preview have separate API references, and Cloudflare recommends the preview for new projects — an API-stability risk. First container build takes 2-3 minutes.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-013",
  "name": "Runloop",
  "category": "sandbox",
  "source_url": "https://docs.runloop.ai/docs/devboxes/overview",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Devboxes are sandboxed cloud workstations for AI coding agents on a custom bare-metal hypervisor with microVM isolation; Blueprints are custom base images and snapshots support branching.",
  "runtime_profiles_supported": "Full lifecycle API covering create, suspend, resume, snapshot, shutdown, sync and async exec, named shell sessions, file I/O, code-repo mounts, network tunnels with HTTPS URLs, SSH keys and a PTY control plane. The HTTPS tunnel makes service-shaped previews viable.",
  "rollback_mechanics": "Snapshot-and-branch from disk state; docs position snapshots for build caches, rollback and fan-out. Disk-state rollback, not release rollback.",
  "verification_depth": "build",
  "production_evidence": "Claims SOC 2 Type II, HIPAA and GDPR compliance with VPC deployment for regulated workloads. Agent Gateways proxy LLM API access and MCP Hub proxies tool servers so real credentials are never exposed to the devbox — a genuinely relevant isolation pattern for running untrusted donor code.",
  "limitations": "Performance figures (sub-second start, 20,000+ concurrent) come from vendor pages rather than an SLA or postmortem; treat as marketing until independently observed. Oriented to agent workstations rather than to releasing a composition.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-014",
  "name": "Blaxel",
  "category": "sandbox",
  "source_url": "https://blaxel.ai/blog/sandbox-vs-runtime-vs-code-interpreter",
  "observed_date": "2026-08-27",
  "evidence_class": "secondary",
  "claim": "MicroVM sandboxes with millisecond boot and ~25ms resume with memory state intact; perpetual standby with no compute charges while standing by.",
  "runtime_profiles_supported": "Session-first stateful runtime aimed at agents running for hours; Volumes provide block storage for retention beyond standby.",
  "rollback_mechanics": "unknown",
  "verification_depth": "unknown",
  "production_evidence": "none_found — all figures observed came from Blaxel's own blog and comparison pages, which are also competitive marketing against E2B and Vercel. Not corroborated from a docs page or SLA in this run.",
  "limitations": "Docs at docs.blaxel.ai were not fetched in this run, so every claim here is vendor-blog grade. The vendor's own taxonomy (runtimes are for trusted code, sandboxes for untrusted) is a useful conceptual frame but is an argument, not evidence. Agent Runtime is a future product (stated Q2 2026).",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-015",
  "name": "Northflank",
  "category": "paas",
  "source_url": "https://northflank.com/docs/v1/application/release/run-and-manage-releases",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Pipelines with release flows as workflow templates; preview blueprints create ephemeral environments per branch or PR.",
  "runtime_profiles_supported": "Multi-service: a single workflow run can contain multiple build and deployment nodes and multiple Git triggers, so a run can span frontend and backend services.",
  "rollback_mechanics": "CONTESTED. Vendor feature pages claim one-click rollback of a release or an entire pipeline stage. The first-party run-and-manage-releases doc read on 2026-08-27 describes no dedicated rollback control — the closest documented mechanism is re-triggering a prior run with the same configuration and arguments. Treat one-click rollback as unverified.",
  "verification_depth": "contract",
  "production_evidence": "Documented run semantics: statuses Pending/Running/Success/Failed, node statuses add Waiting and Retrying with up to 3 attempts, cron minimum interval 10 minutes UTC, webhook query params override trigger fields.",
  "limitations": "The docs page does not state whether a run captures image DIGESTS or an environment snapshot, which is exactly what would make a re-trigger equivalent to a composition rollback. Gap between marketing and docs is itself the finding.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-016",
  "name": "Neon",
  "category": "data_migration",
  "source_url": "https://neon.com/docs/guides/branching-github-actions",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Copy-on-write database branches created in about one second regardless of database size, carrying the parent branch's schema and data; GitHub Actions for create, delete, reset and schema diff.",
  "runtime_profiles_supported": "Data plane for per-PR preview compositions. Branch-per-preview naming convention preview/pr-<n>-<branch>.",
  "rollback_mechanics": "Reset a branch to the latest state of its parent (neonctl branches reset <branch> --parent), discarding changes. This is a data-state reset, not a schema-version revert like PlanetScale's.",
  "verification_depth": "contract",
  "production_evidence": "Documented operational hazards rather than pure upside: branches left beyond the history retention window start incurring cost, and every plan has a branch limit so long-open PRs quietly accumulate branches against it.",
  "limitations": "Branch reset moves toward the parent, so it cannot restore a released branch to a prior pinned state the way a versioned migration revert can. Postgres only. Cleanup on PR close is the integrator's responsibility.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-017",
  "name": "Caddy on-demand TLS",
  "category": "edge_tls",
  "source_url": "https://caddyserver.com/on-demand-tls",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Dynamically provisions TLS certificates at handshake time for hostnames approved by a configured `ask` endpoint returning HTTP 200.",
  "runtime_profiles_supported": "Edge layer, runtime-agnostic; a catch-all site with reverse_proxy fronts any released composition on any subdomain.",
  "rollback_mechanics": "Not applicable.",
  "verification_depth": "contract",
  "production_evidence": "The security model is documented as mandatory rather than optional: without an ask endpoint anyone can trigger issuance for any domain, creating a Let's Encrypt rate-limit attack vector. Performance is favourable — subsequent requests for a known hostname skip the ask call until renewal, so ask is cold-path.",
  "limitations": "MATERIAL RISK to the prior conclusion: for multi-node deployments, shared certificate storage backend modules are NOT in official Caddy builds, so a distributed Caddy fleet requires a CUSTOM BUILD. Also, the ask directive sends a plain GET so the only practical way to attach a secret is in the URL. Hostnames must be normalised to lowercase on both write and read. Note: the distributed-storage and secret-in-URL points were observed via community/secondary sources in this run, not confirmed against Caddy's own module documentation.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-018",
  "name": "Approximated",
  "category": "edge_tls",
  "source_url": "https://approximated.app/docs/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Managed custom domains and SSL via a dedicated reverse proxy cluster per customer with globally distributed edge nodes and a dedicated IPv4 address so apex domains can be pointed at it.",
  "runtime_profiles_supported": "Edge layer, runtime-agnostic. The app identifies the tenant from the hostname or the apx-incoming-host header.",
  "rollback_mechanics": "Not applicable.",
  "verification_depth": "contract",
  "production_evidence": "Concrete integration contract: a six-endpoint virtual hosts API (create, list, read, update, bulk update, delete) authenticated by a private key in an api-key header that must never be exposed client-side. Dedicated IPv4 per cluster is the specific technical fact that makes apex-domain support possible, which CNAME-only approaches cannot do.",
  "limitations": "Managed dependency at the edge — the buy option against Caddy's build option. Uptime and scale characteristics were not verified against an SLA page in this run.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-019",
  "name": "QA Wolf",
  "category": "verification",
  "source_url": "https://docs.qawolf.com/qawolf/Welcome-to-QA-Wolf",
  "observed_date": "2026-08-27",
  "evidence_class": "secondary",
  "claim": "Managed AI-plus-human QA service that maps the application, generates and maintains end-to-end tests as standard Playwright/Appium code, and triages failures.",
  "runtime_profiles_supported": "Runtime-agnostic black-box workflow verification against the deployed surface.",
  "rollback_mechanics": "Not applicable.",
  "verification_depth": "workflow",
  "production_evidence": "Model of interest to Actionist: tests are authored in plain English for review using Arrange/Act/Assert, and a failure is investigated by an AI agent then reviewed by a human engineer before it reaches the customer — so what the developer receives is a triaged reproducible failure with video and logs rather than a raw flake.",
  "limitations": "Claims observed in this run (80% coverage guarantee within four months, zero-flake guarantee, 15-minute full-suite reports) came from vendor and third-party review pages, not from the docs site itself, which was not fetched. Per-test pricing is reported to scale poorly. Treat all figures as unverified marketing.",
  "disposition": "census",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-020",
  "name": "Statsig",
  "category": "release",
  "source_url": "https://docs.statsig.com/autotune/overview",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Autotune multi-armed bandits allocate traffic to optimise a single target metric; Metric Alerts fire when configured thresholds are breached during any rollout or experiment.",
  "runtime_profiles_supported": "Runtime-agnostic, operates at flag/experiment evaluation.",
  "rollback_mechanics": "unknown — NO first-party documentation of automatic rollback was found. Statsig's documented posture is threshold-based ALERTING, not automated reversion. The docs recommend wrapping an autotune in a linked A/B test to monitor guardrails at all.",
  "verification_depth": "unknown",
  "production_evidence": "Docs state a real limitation against the vendor's own interest: Autotune can only optimise for a SINGLE metric, cannot accurately measure a collection of metrics, and is not a reliable way to understand secondary effects of a change.",
  "limitations": "Explicitly weaker than LaunchDarkly's guarded rollouts for Actionist's purpose: alerting requires a human to act, so it does not deliver measured automatic rollback. Guardrail coverage is a documented workaround (90/10 holdback or 50/50 wrapper), not a native feature.",
  "disposition": "excluded",
  "top10_rank": null,
  "top10_rationale": null
}

{
  "id": "P14-C-021",
  "name": "Datadog APM (service page, dependency map, Error Tracking, deployment tracking)",
  "category": "observability",
  "source_url": "https://docs.datadoghq.com/tracing/services/service_page/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Datadog APM attributes errors along four documented axes on the service page: aggregated into issues by Error Tracking, broken down by resource (endpoint), by version via the Deployments tab, and by downstream dependency. Clicking a dependency node scopes metrics so that 'request count, errors, and latency metrics are scoped to requests going from the service to the downstream dependency', letting you 'identify slow or failing queries'. The dependency map is 'powered by APM metrics to surface accurate request counts, error rates, and latency numbers' and inferred dependencies such as databases or queues are shown as separate nodes.",
  "attribution_granularity": "dependency",
  "required_metadata": "Unified Service Tagging: service, env, version tags on every emitting component. Monitors attach only when 'service:<SERVICE_NAME> is tagged in the metadata, included in the monitor query, or if the query is grouped-by service'. Version tags are what populate the Deployments tab. For user/account attribution RUM+APM must be connected with usr.id and account.id attributes, else 'Datadog cannot attribute activity to specific users or accounts'. Requires tracing instrumentation (agent/library) in each component.",
  "rollback_signal": "alert_only — Automatic Faulty Deployment Detection is enabled by version tagging, but the docs describe only notification: 'You can set up a monitor to get automatically notified on all potentially faulty deployments' (tags:deployment_analysis). No automated rollback described.",
  "production_evidence": "Documented product behavior across service_page and deployment_tracking docs; no independent production case study fetched.",
  "limitations": "Deployment error comparison is explicitly non-causal: the Error Types indicator 'doesn't mean that this version necessarily introduced these errors', and a rare error 'might be listed as no longer appearing only because it has not been seen yet'. Version section only renders when multiple versions report in the window. Span summaries and service/resource statistics retained up to 30 days. Dependencies section limited to specific Datadog sites.",
  "disposition": "census"
}

{
  "id": "P14-C-022",
  "name": "Datadog Software Catalog (Internal Developer Portal)",
  "category": "observability",
  "source_url": "https://docs.datadoghq.com/service_catalog/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "The Catalog is 'a centralized, dynamic view of your software ecosystem and infrastructure resources', 'Built on real-time telemetry and automated metadata collection'. Entities register three ways: Datadog 'detects it from telemetry', 'You declare it in an Entity Definition', or 'You import it from a third-party source' (Backstage, ServiceNow). It groups and filters on 'ownership, tier, life cycle, and definition version', and the Ownership view lets you 'Access your team's Slack, repo, or on-call information'. The Relationships view shows 'the dependency graph for services' and links infrastructure resources to the software entities that run on them.",
  "attribution_granularity": "service",
  "required_metadata": "An Entity Definition per component (or telemetry emitting a recognizable service) plus ownership metadata (team, Slack, repo, on-call). Service type is NOT customer-supplied — 'Datadog automatically determines type based on the span.type attribute attached to incoming spans data'.",
  "rollback_signal": "alert_only — the Reliability view surfaces 'entities with recent deploys, rising error rates, open incidents, or failing monitors' for triage; no rollback action documented at the catalog layer.",
  "production_evidence": "none_found",
  "limitations": "'Span summaries and service and resource statistics are retained for up to 30 days'; longer-horizon attribution needs Metric Explorer against APM trace metrics. Catalog quality is only as good as the declared entity definitions.",
  "disposition": "census"
}

{
  "id": "P14-C-023",
  "name": "Honeycomb BubbleUp",
  "category": "observability",
  "source_url": "https://docs.honeycomb.io/investigate/analyze/identify-outliers",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "BubbleUp 'displays outliers and explains how a subset of data differs from other data'. The user selects a region (typically a heatmap box); Selection 'contains the points in the area selected in the heatmap' and Baseline 'contains all the points outside of the area selected'. Every field becomes a chart, split into Dimensions ('fields with categorical or ordinal values') and Measures ('fields with numeric values'), ranked by deviation. Attribution lands at the field-VALUE level: the docs' worked example finds that 'the /api/v2/tickets/export endpoint is responsible for the slow requests'. This is the strongest documented general mechanism for 'which attribute explains this anomaly' — if capability identity is an instrumented attribute, BubbleUp will surface it as the explaining dimension.",
  "attribution_granularity": "dependency",
  "required_metadata": "The attribute you want to attribute to MUST be present as a field on the events. BubbleUp can only surface what is instrumented: 'A dataset or environment has many fields' and 'BubbleUp represents each field with a chart'. Field coverage is variable and shown as a ratio because 'A field and its values may not be populated in a dataset or environment'. No ownership file or service registry is required — the mechanism is purely attribute-driven, which makes it the least prescriptive and most composable of the attribution systems surveyed.",
  "rollback_signal": "alert_only — BubbleUp is an interactive investigation surface; no deploy gate or rollback action documented.",
  "production_evidence": "Documented worked example in first-party docs (app.endpoint attribution to /api/v2/tickets/export); no third-party production case fetched.",
  "limitations": "Requires a human-drawn selection, so it is not an automated attribution pipeline. 'BubbleUp works best when the data in the selection contrasts the data in the baseline'; 'Bigger time ranges may display greater variance across the data'. Bar chart 'displays a maximum of seventy-five values'. Baseline is the complement of the selection within the same query, not a historical norm. Nominal high-uniqueness fields (e.g. trace.span_id) behave differently.",
  "disposition": "census"
}

{
  "id": "P14-C-024",
  "name": "Sentry (issue ownership rules + CODEOWNERS)",
  "category": "observability",
  "source_url": "https://docs.sentry.io/product/issues/ownership-rules/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Sentry attributes an issue to an owner via rules of form 'type:pattern owners' with four match types: path (file paths in the stack trace), module (module names in the stack trace), url (the request URL of the event), and tags.TAG_NAME (a particular event tag). Evaluation is code owners first then ownership rules, and 'The last rule that matches is used for issue assignment'. Critically for composed apps, the tags: match type means attribution can be driven by an arbitrary event tag — i.e. a capability identifier — not only by source path.",
  "attribution_granularity": "commit",
  "required_metadata": "Either hand-written ownership rules (glob patterns, not regex — 'Use * to match anything and ? to match a single character'), or a CODEOWNERS import which requires Business/Enterprise plan, code mappings from stack trace linking, and external team/user mappings ('Sentry automatically ignores rules that are missing team/user mappings'). Owners must be Sentry user emails or #team names.",
  "rollback_signal": "alert_only — drives assignment/notification routing, not a deploy gate.",
  "production_evidence": "none_found",
  "limitations": "'Once an issue has been assigned (whether manually or automatically), future auto-assignment will be turned off for that issue'. High issue-creation volume triggers rate limits that skip auto-assignment. CODEOWNERS files cap at 3MB and sync periodically, not instantly. GitLab sections and ! negations unsupported. Path/module rules attribute to YOUR repo layout — they do not distinguish a fault inside a third-party dependency from a fault in your own code unless in-app framing or tags do so.",
  "disposition": "census"
}

{
  "id": "P14-C-025",
  "name": "Sentry Suspect Commits",
  "category": "observability",
  "source_url": "https://docs.sentry.io/product/issues/suspect-commits/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Sentry attributes an error to a specific commit and author: it will 'show you the most recent commit to the code in your stack trace' and displays 'the author of the commit and the pull request in which the commit was made'. Mechanism is documented precisely: Sentry 'will look at the stack trace of an issue and collect all in-app frames', then 'For each in-app frame, Sentry checks the blame info for the exact file and line number', with a recency filter — 'If the most recent commit is less than 1 year old, we consider it a suspect commit'. 'The first frame in the stack trace is considered suspect when looking at them top-down'. This is the finest attribution granularity found in the survey.",
  "attribution_granularity": "commit",
  "required_metadata": "Four things: (1) uploaded source maps / debug files — 'In order to see suspect commits, you have to first upload source maps'; (2) a GitHub or GitLab repository integration; (3) code mappings translating stack trace paths to repo paths (Stack Trace Root / Source Code Root, plus Project, Repo, Branch); (4) optionally commit association with releases as a fallback — 'Sentry will fall back to using the release commit data to find suspect commits'.",
  "rollback_signal": "alert_only — feeds suggested assignees and auto-assignment ('If an issue has not been assigned and a suspect commit is found, Sentry assigns it to the commit author'). No rollback action.",
  "production_evidence": "none_found",
  "limitations": "'This feature is only applicable for error issues' — performance and replay issues excluded. 'Sentry will not display suspect commits for issues that were created before your integration was set up'. Fails when there is no stack trace, no in-app frames, frames not matching code mappings, or commits older than a year. Only GitHub and GitLab supported. Attribution is to code in YOUR repo — a fault originating in an unmodified donor dependency will not have in-app frames and therefore no suspect commit.",
  "disposition": "census"
}

{
  "id": "P14-C-026",
  "name": "Sentry Release Health (crash-free sessions/users)",
  "category": "release",
  "source_url": "https://docs.sentry.io/product/releases/health/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Release health scores a release version by session outcome. Crash-free sessions is 'the percentage of sessions in the specified time range not ended by a crash of the application'; crash-free users is 'the percentage of distinct users who did not experience a crash during the specified time period'. Session statuses are healthy, errored, crashed, unhandled, and abnormal, where abnormal means 'the SDK cannot determine whether the session ended gracefully or not'. As of v25.9.0 'Sentry differentiates between crashes and unhandled errors; both are counted separately'.",
  "attribution_granularity": "deploy",
  "required_metadata": "Release and environment identifiers plus session tracking in the SDK. The session dataset 'tracks every session start and end, and includes only basic tags related to release and environment'. Sessions are often automatic — 'Many SDKs automatically manage the start and end of sessions when the SDK is initialized' — but long-lived background apps need manual session tracking.",
  "rollback_signal": "alert_only — the only automation documented is 'You can set crash rate monitors to tell you when your crash free percentage for either sessions or users falls below a specific threshold'. Nothing in the docs halts a rollout or reverts a release; consuming the signal in your own deploy tooling is left to the customer.",
  "production_evidence": "none_found",
  "limitations": "Attribution granularity is the RELEASE, not a component within it — a single crash-free number for a composed app cannot say which capability crashed. Session data 'are not subject to inbound filters or sampling' while issues are, so 'One common misconception is that session data is derived from issues, and that the numbers can be cross referenced. This is not the case'. Adoption stage is explicitly descriptive, not a gate.",
  "disposition": "census"
}

{
  "id": "P14-C-027",
  "name": "New Relic Errors Inbox",
  "category": "observability",
  "source_url": "https://docs.newrelic.com/docs/errors-inbox/errors-inbox/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "New Relic groups errors by fingerprint — 'Error events get grouped into an error group when they share the same fingerprint' — with fingerprint inputs including account ID, entity ID, error class, error message, stack trace, and exception. Managed rules normalize data first, 'identifying and ignoring unique values such as UUIDs, hex values, and email addresses'. Primary attribution axis is the entity: 'Error groups are tied to the entity'. Version attribution exists via 'Occurrences by version: How many times the error occurred per deployment version'. Customers can override grouping by designating error.group.name.",
  "attribution_granularity": "service",
  "required_metadata": "Instrumentation reporting a distinct entity ID per component. Optionally error.group.name as an agent-designated group or custom attribute (supported in Browser, Go, Java, Node.js, .Net, Python, Ruby, PHP agents); for unsupported languages setting error.group.name as a custom attribute still works 'though the events captured won't have other agent attributes'. Deployment version reporting for the by-version breakdown.",
  "rollback_signal": "alert_only — resolution statuses can target 'the next version or in a specific version', but no automated rollback is documented on this page.",
  "production_evidence": "none_found",
  "limitations": "No commit-level attribution — 'the page contains no commit-level attribution'. A single app reporting as multiple entities (separate clusters or cells) 'may produce duplicate groups' because fingerprinting reads account and entity IDs; the documented fix is consolidating into one entity, which is the OPPOSITE of what a composed-capability model wants. Message hygiene matters: high-variability values in messages fragment groups. Read-only users can still assign error groups.",
  "disposition": "census"
}

{
  "id": "P14-C-028",
  "name": "PagerDuty (technical services + escalation policies)",
  "category": "incident",
  "source_url": "https://support.pagerduty.com/main/docs/services-and-integrations",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "PagerDuty models ownership per component by construction: 'A technical service reflects a discrete piece of functionality that is wholly owned by one team', and 'One or more technical services combine to deliver business capabilities'. Components 'can be applications, micro-services in an application's architecture, or cross-cutting shared infrastructure'. Routing is two-step: integrations feed events into a service (each with an Integration Key placed in the sending tool), and the service's escalation policy assigns the resulting incident.",
  "attribution_granularity": "service",
  "required_metadata": "One PagerDuty service per component you want to attribute to, an integration key per emitting source routed to that service, and an escalation policy per service. The sending system must choose the correct integration key — i.e. the emitter must already know which capability it is. PagerDuty does not derive the component; it consumes a routing decision made upstream.",
  "rollback_signal": "alert_only — routes a human incident, no deploy control.",
  "production_evidence": "none_found",
  "limitations": "Attribution is exactly as good as the routing key the emitter picks — PagerDuty is a sink for an attribution decision, not a source of one. Single-team ownership per service is enforced by the model. A service 'cannot have more than 250 integrations'. Manager team roles can only manage services associated with their team. Integrations with more than 8,000 open incidents cannot be moved.",
  "disposition": "census"
}

{
  "id": "P14-C-029",
  "name": "Dynatrace Davis AI (root cause analysis)",
  "category": "observability",
  "source_url": "https://docs.dynatrace.com/docs/platform/davis-ai/root-cause-analysis/root-cause-analysis-concepts",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Davis performs automatic cross-dependency root cause attribution rather than presenting a dashboard. Its 'context model is built on known dependency information from Smartscape, OneAgent, and cloud integration', and Dynatrace 'uses this information to quickly conduct a fault tree analysis to analyze millions of dependencies and arrive at the most probable root cause'. The docs explicitly reject correlation-by-time: 'time correlation alone is not sufficient', and 'all topological dependencies, vertical and horizontal, are part of the analysis'. Root cause is attributed down the stack — application entry point, service, process ('high GC activity on underlying Java processes'), and code ('failing methods within your service code') — and users can 'drill down to the component level and analyze the root cause down to the source code level'. Davis 'combines multiple standalone anomalies into a single consistent problem' and 'correlates all Davis events with the same root cause into a single problem'.",
  "attribution_granularity": "dependency",
  "required_metadata": "OneAgent deployed on every host/process plus cloud integrations — the topology is auto-discovered from agent observation, NOT from customer-declared dependency metadata. This is the key contrast with Datadog: Dynatrace derives the dependency graph itself, so the customer supplies agent coverage rather than tags. Composed capabilities not covered by OneAgent fall outside the fault tree.",
  "rollback_signal": "alert_only at the analysis layer — Davis emits a ranked problem with a root-cause entity; the docs surveyed do not describe automated rollback (Dynatrace sells separate automation/workflow products not verified here).",
  "production_evidence": "Documented mechanism with worked example (Booking service slowdown attributed to downstream Verification service); no independent production case fetched.",
  "limitations": "Output is probabilistic — contributors are ranked to determine 'which is the primary negative impact', not a deterministic verdict. Requires OneAgent-level access to the runtime, which a composed app built from heterogeneous hosted donor services may not be able to grant uniformly. Problems within 30 minutes sharing a root cause are consolidated as duplicates, which can mask repeat signal.",
  "disposition": "census"
}

{
  "id": "P14-C-030",
  "name": "Grafana Cloud Application Observability",
  "category": "observability",
  "source_url": "https://grafana.com/docs/grafana-cloud/monitor-applications/application-observability/setup/resource-attributes/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Grafana Cloud Application Observability is 'application performance monitoring (APM) powered by OpenTelemetry' and states its attribution contract as five explicit resource attributes: service.namespace ('An optional namespace for service.name'), service.name ('The application name'), deployment.environment ('Name of the deployment environment (staging or production)'), service.instance.id ('The unique instance, e.g. the pod name'), and service.version ('The application version, to see if a new version has introduced a bug'). These attributes 'allow you to filter your metrics and traces effectively'. This is the most explicit statement in the survey of the minimum identity contract for per-component attribution, and it is vendor-neutral because it is plain OpenTelemetry semantic convention.",
  "attribution_granularity": "service",
  "required_metadata": "OpenTelemetry SDK instrumentation in each component emitting the five resource attributes above, plus Grafana Alloy (an OpenTelemetry Collector) in the pipeline. Label mapping is deterministic: job is built from '${service.namespace}/${service.name}' when a namespace is set, otherwise the service name alone; instance is populated from service.instance.id.",
  "rollback_signal": "alert_only — service.version exists specifically 'to see if a new version has introduced a bug', but no deploy gate or rollback is documented.",
  "production_evidence": "none_found",
  "limitations": "The docs 'don't formally split these into required versus recommended tiers' — only service.namespace is marked optional, so the strictness of the contract is inferred rather than stated. Docs use the older deployment.environment form, not deployment.environment.name; the newer naming could not be confirmed from this page. Attribution granularity stops at service/instance — no commit-level attribution documented here.",
  "disposition": "census"
}

{
  "id": "P14-C-031",
  "name": "incident.io (alert attributes + alert routes + Catalog)",
  "category": "incident",
  "source_url": "https://docs.incident.io/alerts/attributes-and-priorities",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "incident.io models per-component ownership through a normalization layer plus a Catalog lookup. Alert attributes are 'how you extract a consistent format of data from your different alert sources, to use in your alert routes' — the docs' own example is that 'your Grafana alerts might have a team label, while BugSnag alerts have service and customer tags', normalized so 'your alert routes don't have to think about where an alert has come from'. Routing is then dynamic: the docs recommend you 'leverage Expressions to dynamically pick the right Escalation Path depending on the alert's context', specifically 'a query-based expression to pick the right Path based on e.g. the impacted Service or Team on the alert'. Catalog holds 'services, teams, domains, features, integrations etc.' This normalization layer is the closest commercial analogue to what a composed-app host would need: heterogeneous emitters, one canonical capability identifier.",
  "attribution_granularity": "service",
  "required_metadata": "An attribute on every alert identifying the responsible Service or Team, mapped from each source's native payload shape, plus Catalog entries the expression can resolve to an escalation path. Attributes can be marked required, which makes incident.io 'warn you if your alert sources don't have this attribute configured correctly' and 'notify you if we detect alerts that are missing a value for this attribute' — an explicit contract-enforcement mechanism.",
  "rollback_signal": "alert_only — pages a human; auto-cancel withdraws pages when an alert resolves, 'useful for flappy alert sources'.",
  "production_evidence": "none_found",
  "limitations": "Attribution is only as good as the attribute the emitter supplies — if the Team attribute is missing 'then it may not be escalated and nobody will get paged'. Marking an attribute required is 'global configuration, so you should only do this for attributes which you expect to be set on every alert', so the contract is all-or-nothing per attribute. incident.io consumes an attribution decision; it does not compute one from telemetry.",
  "disposition": "census"
}

{
  "id": "P14-C-032",
  "name": "Bugsnag / Insight Hub (releases and versions)",
  "category": "release",
  "source_url": "https://docs.bugsnag.com/product/releases/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Bugsnag correlates errors to a release using two required pieces of configuration — app version and release stage — which let you 'filter your dashboard by release and identify which release errors were introduced in' and 'see release annotations on the timeline to correlate new versions with changes in error rates'. Optional build/source-control enrichment (repo name and commit hash) adds links to 'the version of your code in that release, and the diff from the previous release', plus stack traces that link 'directly to view the line of code (on some platforms)'.",
  "attribution_granularity": "deploy",
  "required_metadata": "App version (auto-detected on some platforms, e.g. Android versionName/versionCode and iOS Version/Build; set manually elsewhere) and release stage (usually auto-detected; 'the release stage will default to production' if neither auto-detection nor manual setting occurs). Optionally repo name + commit hash via build tool integrations for source-level linking.",
  "rollback_signal": "alert_only — nothing on the releases page indicates stability data gates deploys or triggers rollbacks; described capabilities are 'filtering, annotations, and correlation of releases with error-rate movement'.",
  "production_evidence": "none_found",
  "limitations": "Stability score formula and stability targets are NOT defined on this page (the stability center is only named in passing); UNVERIFIED whether targets can gate anything. The Build API autoAssignRelease fallback is 'constrained to single-version-at-a-time deployments such as server-side apps' and the docs caution that 'errors reported around the time of a release may be associated with the wrong version' — a direct hazard for a composed app where capabilities deploy independently.",
  "disposition": "census"
}

{
  "id": "P14-C-033",
  "name": "Harness Continuous Verification (Verify step)",
  "category": "release",
  "source_url": "https://developer.harness.io/docs/continuous-delivery/verify/verify-deployments-with-the-verify-step/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Harness CV is one of only two systems in this survey where an observability signal deterministically drives an automatic rollback. It 'integrates with APMs and logging tools to verify that the deployment is running safely and efficiently', 'uses machine learning to establish a baseline of normal behavior from your historical data', and the docs state plainly: 'During the AI Verify (v1) step, Continuous Verification automatically triggers a rollback if anomalies are found.' Canary node classification is mechanical, not inferred — a pod seen both before and after deploy is stable; one appearing only afterward 'is identified as a canary pod'. Sensitivity maps to standard-deviation cutoffs: High 1 sigma, Medium (default) 2 sigma, Low 3 sigma; 'Unhealthy' fails at every level.",
  "required_metadata": "A Harness Monitored Service mapping a Harness Service to a service in the APM/logging tool — i.e. an explicit two-sided identity binding between the deploy unit and the telemetry unit. Plus a Service Instance Identifier (SII), 'a filter to pinpoint metrics related to what has been deployed', which is what makes per-component attribution possible. Plus a health source ('an APM or logging tool that monitors and aggregates data in your deployment environment'). This SII/monitored-service pairing is the single most transferable artifact found for Actionist: the deploy system and the telemetry system must agree on one identifier.",
  "attribution_granularity": "deploy",
  "rollback_signal": "automatic_rollback — verified first-party. Fail-fast thresholds mark the deployment failed immediately, after which configured failure strategies (rollback or manual intervention) run. Fail-fast works for metrics but not logs, 'since log clustering needs the full window'.",
  "production_evidence": "Documented product mechanism; no independent production case study fetched.",
  "limitations": "Requires historical data to build the ML baseline, so a newly composed capability with no history has no baseline — a cold-start problem directly relevant to Actionist assembling novel apps. High sensitivity 'produces false positives on inherently noisy metrics like latency'; per-metric sensitivity override is behind a feature flag (CDS_CV_PER_METRIC_SENSITIVITY) and applies to metric sources only, not logs. Note the separate Harness post-deployment rollback feature is MANUAL, not automatic — see P14-C-034.",
  "disposition": "census"
}

{
  "id": "P14-C-034",
  "name": "Harness post-deployment rollback",
  "category": "release",
  "source_url": "https://developer.harness.io/docs/continuous-delivery/manage-deployments/rollback-deployments/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Distinct from Continuous Verification: 'Post deployment rollback initiates a rollback of your most recent successful deployment' and is user-initiated on every documented path (services dashboard, environment dashboards, pipeline execution page behind CDS_ROLLBACK_OPTION, or 'programmatically using Harness APIs'). Recorded separately from P14-C-033 because the two are frequently conflated and only the Verify step is automatic.",
  "attribution_granularity": "deploy",
  "required_metadata": "A prior successful Harness deployment of a supported type, with rollback steps present in the stage — 'Only the rollback steps that are part of the stage can be used during rollback.'",
  "rollback_signal": "manual_rollback (API-triggerable) — no automatic triggering documented on this page.",
  "production_evidence": "none_found",
  "limitations": "Supported types limited to Kubernetes, ASG, TAS, ECS, Native Helm, MIG. 'You can rollback successful pipelines only. The rollback option is not available for failed pipelines.' 'You cannot roll back the same pipeline multiple times.' 30-day window on post-production rollbacks. Executions marked successful by an ignore-failures strategy cannot be rolled back.",
  "disposition": "census"
}

{
  "id": "P14-C-035",
  "name": "Argo Rollouts (AnalysisTemplate / AnalysisRun)",
  "category": "release",
  "source_url": "https://argo-rollouts.readthedocs.io/en/stable/features/analysis/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "The second genuine automatic-rollback mechanism found, and the only one with a fully declarative, portable contract. An AnalysisTemplate defines metrics backed by a provider (Prometheus, Datadog, NewRelic, Wavefront, Kayenta, CloudWatch, Graphite, InfluxDB, SkyWalking, Job, Web, or custom plugins) with per-measurement successCondition and failureCondition expressions (e.g. 'result[0] >= 0.95'). Failure aborts automatically: for background canary analysis, 'The failed analysis causes the Rollout to abort, setting the canary weight back to zero, and the Rollout would be considered in a Degraded'; for blue-green post-promotion, 'If post-promotion Analysis fails or errors, the Rollout enters an aborted state and switches traffic back to the previous stable Replicaset.'",
  "attribution_granularity": "deploy",
  "required_metadata": "A metric query that isolates the component under test — the customer supplies the query, so per-component attribution is achieved by whatever label/tag the query filters on. Args can be templated from Secrets via secretKeyRef, Rollout labels, status fields, or pod-template fields and resolved as '{{ args.<name> }}'. failureLimit ('the maximum number of failed run an analysis is allowed', default 0) and consecutiveSuccessLimit (v1.8+) tune tolerance.",
  "rollback_signal": "automatic_rollback — verified first-party, with the abort semantics quoted above.",
  "production_evidence": "Widely deployed CNCF project; no specific production case fetched in this pass.",
  "limitations": "Attribution is entirely the customer's responsibility — Argo evaluates an expression against a query result and has no model of services, ownership, or dependencies. Ambiguous results stall rather than decide: 'Inconclusive runs causes a rollout to become paused at its current step. Manual intervention is then needed to either resume the rollout, or abort.' Edge cases (NaN, +Inf, empty arrays) must be handled explicitly in the condition expression or the run misbehaves. dryRun metrics 'won't impact the final state of the rollout or experiment even if it fails'. Kubernetes-only.",
  "disposition": "census"
}

{
  "id": "P14-C-036",
  "name": "Harness FME (formerly Split) — metric alerts and flag kill",
  "category": "release",
  "source_url": "https://developer.harness.io/docs/feature-management-experimentation/release-monitoring/alerts/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "FME attributes a metric degradation to a specific feature flag using a baseline treatment as control, which 'minimize[s] false positives'. Three mechanisms: automatic significance alerts on key metrics (only when the 'When a key metric reaches significance' option is enabled), automatic significance alerts on guardrail metrics ('Guardrail metric alerts are automatically evaluated'), and manual metric alert policies where you 'define thresholds and recipients'. Significance alerts 'are automatic and require no threshold configuration'. Notably this is per-FLAG attribution — the flag is the unit of blame, which is the closest commercial analogue to per-capability attribution when a capability is gated behind its own flag.",
  "attribution_granularity": "service",
  "required_metadata": "Metrics measured per traffic type (alert policies 'can only be created for metrics measured per traffic type'), a baseline treatment as control group, SDK impression/event data tying users to treatments, and per-flag alert settings for key-metric significance.",
  "rollback_signal": "alert_only_with_manual_kill — the docs frame killing as a human decision: 'If you decide to kill a feature flag due to an alert, the default treatment overrides the existing targeting rules and is returned for all users.' Nothing indicates FME kills a flag on its own. An Admin API kill endpoint exists for programmatic rollback driven by your own automation.",
  "production_evidence": "none_found",
  "limitations": "Statistical, therefore sample-hungry: at least 355 samples in both treatments are required before significance can be confidently tested (secondary source; UNVERIFIED against the primary alerts page). Significance alerts are production-only. 'The default monitor window is 24 hours' and 'The monitoring window only applies to alert policies'. FME 'continues to monitor and alert your team of a metric degradation for up to 28 days after a version change'. Requires enough traffic per capability to reach significance — a low-traffic composed client app may never trigger.",
  "disposition": "census"
}

{
  "id": "P14-C-037",
  "name": "Unleash (impression data)",
  "category": "release",
  "source_url": "https://docs.getunleash.io/reference/impression-data",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Unleash emits per-evaluation telemetry but performs no attribution or gating itself. 'The client SDK will emit an impression event when it calls isEnabled or getVariant', carrying eventType, eventId (a GUID), context (a snapshot of the Unleash Context), enabled, featureName, and for variant calls a variant field. The stated purpose is analytical — to 'collect analytics data', 'perform A/B tests', and 'enrich experiments' — and the documented pattern is to 'Capture the event here and pass it to internal data lake or analytics provider'. Recorded as a negative/boundary case: it supplies the raw per-flag signal an external attribution system would consume.",
  "attribution_granularity": "none",
  "required_metadata": "Per-flag opt-in: 'Impression data is opt-in on a per-flag basis', toggled at flag creation/edit or via the API's impressionData option. Flags without it enabled produce no events at all. Requires SDK compatibility (v4.7+).",
  "rollback_signal": "alert_only — in fact not even that. Nothing describes automatic rollback, kill-switch automation, or health-based gating; 'Any rollback logic would be something you build downstream from that data; Unleash does not act on it for you.'",
  "production_evidence": "none_found",
  "limitations": "No evaluation-reason API — 'Unleash SDKs do not expose an evaluation reason API'; debugging why a flag evaluated a given way requires the Playground. Frontend SDKs receive only enabled flags from Edge or the Frontend API, so disabled flags typically generate nothing. Licence/edition gating of this feature could not be determined from this page (UNVERIFIED).",
  "disposition": "census"
}

{
  "id": "P14-C-038",
  "name": "Flagsmith",
  "category": "release",
  "source_url": "https://docs.flagsmith.com/advanced-use/real-time-flags",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Flagsmith provides real-time flag delivery but the page examined shows no release-health monitoring, automatic rollback, or per-flag degradation attribution. 'Your application subscribes to real-time flag updates by opening a long-lived server-sent events (SSE) connection to Flagsmith', and 'Real-time flag update events only contain a timestamp indicating when any flag in the environment was last updated' — i.e. the event carries no health or outcome signal. Recorded as an excluded/boundary case for the attribution question.",
  "attribution_granularity": "none",
  "required_metadata": "An Enterprise subscription for real-time updates ('Real-time flag updates require an Enterprise subscription') and an SSE client.",
  "rollback_signal": "alert_only — no rollback or gating mechanism found on this page.",
  "production_evidence": "none_found",
  "limitations": "Scope caveat: only the real-time-flags page was examined, so the absence of health monitoring elsewhere in the product is UNVERIFIED rather than established. Identity-level operations 'will not cause updates to be sent'. Licence terms not stated on this page; open-source presence signalled only by GitHub links, copyright 'Bullet Train Ltd.'",
  "disposition": "excluded"
}

{
  "id": "P14-C-039",
  "name": "Datadog Synthetic Monitoring + Continuous Testing (CI/CD)",
  "category": "verification",
  "source_url": "https://docs.datadoghq.com/continuous_testing/cicd_integrations/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Datadog Continuous Testing runs synthetic tests inside pipelines explicitly 'to block branches from being deployed and breaking your application in production'. On the CD side the docs claim post-deploy tests let you 'detect potential regressions that may impact your users and automatically trigger a rollback when a critical test fails' — the only vendor in this survey whose synthetic-test docs assert a rollback trigger. Test types (from the synthetics overview) span API single and multistep (HTTP, SSL, DNS, WebSocket, TCP, UDP, ICMP, gRPC), browser tests, mobile application tests, network path tests, and agentic goal-based tests. Tests can be grouped into Test Suites 'grouped by user journey, environment, location, service, or team'.",
  "attribution_granularity": "endpoint",
  "required_metadata": "Tests authored per endpoint/journey and tagged so they can be selected in CI, e.g. 'datadog-ci synthetics run-tests --config fileconfig.json -s tag:staging'. Trigger via the @datadog/datadog-ci package which 'allows you to run Continuous Testing tests directly within your CI/CD pipeline', or POST /api/v1/synthetics/tests/trigger/ci (up to 100 tests per request). Prebuilt integrations: Azure DevOps, CircleCI, GitHub Actions, GitLab, Jenkins, Bitrise.",
  "rollback_signal": "automatic_rollback (claimed) — the docs assert automatic rollback on critical test failure, but the MECHANISM is not documented on this page and no exit-code or blocking/non-blocking flag is specified. Treat the rollback claim as first-party assertion, weaker evidence than Harness CV or Argo Rollouts where the abort semantics are spelled out.",
  "production_evidence": "none_found",
  "limitations": "The page 'does not mention specific exit codes returned by datadog-ci, nor any per-test blocking vs. non-blocking flag'. Attribution is to a failing test (i.e. a user journey or endpoint), not to the underlying component — a browser test failure tells you the checkout flow broke, not which composed capability caused it, unless APM trace correlation is also wired up. Datadog Synthetics can correlate to APM traces to 'find the root cause of failures across frontend, network, and backend requests', which is the bridge back to per-component attribution.",
  "disposition": "census"
}

{
  "id": "P14-C-040",
  "name": "Grafana Cloud k6 (thresholds)",
  "category": "verification",
  "source_url": "https://grafana.com/docs/k6/latest/using-k6/thresholds/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "k6 provides a precise, portable machine-readable pass/fail contract. 'Thresholds are the pass/fail criteria that you define for your test metrics'; if missed, 'the test finishes with a failed status'. Exit-code semantics are explicit: when all pass, 'k6 considers this test a pass and exits with an exit code 0', and on failure 'k6 would exit with a non-zero exit code'. Thresholds can be scoped by tag or group, e.g. 'http_req_duration{type:API}' — which is the mechanism that would let a composed app assert per-capability performance criteria in one test run. abortOnFail terminates early: 'If you want to abort a test as soon as a threshold is crossed, set the abortOnFail property to true.' Grafana Cloud k6 is 'a fully-managed cloud testing solution... powered by k6 OSS'.",
  "attribution_granularity": "endpoint",
  "required_metadata": "Threshold expressions of form '<aggregation_method> <operator> <value>' keyed by metric name inside options.thresholds. For per-component attribution the customer must TAG requests by capability and scope thresholds to those tags. Aggregation methods are metric-type-dependent (Counter: count/rate; Gauge: value; Rate: rate; Trend: avg/min/max/med/p(N)).",
  "rollback_signal": "gate — a failed threshold produces a non-zero exit code, so 'CI systems that check exit status will mark the job as failed'. This gates a pipeline; it does not itself roll back a live deployment.",
  "production_evidence": "none_found",
  "limitations": "Sharp footgun: repeating the same metric name as separate object keys means 'The rest will be silently ignored' — use an array. 'unlike thresholds, checks do not affect the exit status of k6', so assertions must be wrapped in a threshold on the checks metric (e.g. checks: ['rate>0.9']) to actually break a build. In cloud runs 'thresholds are evaluated every 60 seconds', so abortOnFail may lag by up to a minute. Percentiles outside 0-100 cause a parse error before the run starts.",
  "disposition": "census"
}

{
  "id": "P14-C-041",
  "name": "Chromatic",
  "category": "verification",
  "source_url": "https://www.chromatic.com/docs/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Chromatic is 'a testing platform that scans every possible UI state across browsers to catch bugs in appearance, functionality, and accessibility', from 'the team behind Storybook', integrating with Storybook, Playwright, and Cypress. Its attribution unit is the story, and therefore the component: stories 'capture all states and variations of a component' and Chromatic 'uses these stories to power visual tests', automatically converting them into tests. Accessibility runs 'axe on each component to identify accessibility violations'. For E2E it archives the UI, replays it in cloud browsers, and finds 'visual regressions through pixel diffing'. This per-component granularity is directly relevant to a microfrontend capability in a composed app.",
  "attribution_granularity": "service",
  "required_metadata": "A Storybook (or Playwright/Cypress) with stories covering each component state — the composed capability must expose its UI states as stories for Chromatic to attribute a regression to it. Viewport/browser combinations are configurable (Chrome, Firefox, Safari, Edge).",
  "rollback_signal": "gate (partial) — tests run 'Every time you push code'. The docs' only direct build-blocking statement is an exception: unstable tests are flagged and 'won't block your build', implying real changes can affect build status, but PR-gating mechanics are NOT spelled out on this page. UNVERIFIED whether it enforces a required status check.",
  "production_evidence": "none_found",
  "limitations": "Requires the component to be renderable in isolation as a story — an intact donor service rendering server-side HTML is not covered by this model. Human sign-off is part of the loop ('enables you to assign reviewers and resolve discussions'), so it is not a fully automated gate. Detects visual/a11y regressions only, not runtime failures in production.",
  "disposition": "census"
}

{
  "id": "P14-C-042",
  "name": "Percy (BrowserStack)",
  "category": "verification",
  "source_url": "https://www.browserstack.com/docs/percy/overview/visual-testing-basics",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Percy 'Compares new screenshots against previously approved ones (baseline) to highlight any unintended visual differences' and 'Provides a visual difference view, making it easy to spot pixel-level changes', captured 'across a range of browsers and multiple responsive widths on desktop and mobile devices'. Baseline selection is automatic — 'Percy uses a variety of strategies to determine the optimal base build for comparison on every build you create'. Unlike Chromatic, PR gating is explicitly documented: 'You can optionally set Percy builds up as a blocker to merge in GitHub repository settings.'",
  "attribution_granularity": "app",
  "required_metadata": "Snapshot instrumentation in the test suite plus a source-control integration for status reporting. Review can occur at three levels: 'you can approve individual snapshots with visual changes, entire snapshot groups, or even whole builds.'",
  "rollback_signal": "gate — optional merge blocker in GitHub repository settings; Percy 'automatically updates your pull request or commit status'. Pre-merge only; no production rollback.",
  "production_evidence": "none_found",
  "limitations": "Attribution is to a snapshot (a page/viewport state), not to a component or capability — weaker than Chromatic for composed-app blame assignment. 'Only one snapshot needs to be marked as Changes requested for the entire build status to be updated to match', so a single unrelated diff blocks the whole build. Auto-approval is on for the main branch by default, which can silently absorb a regression. Requested changes revert to 'Unreviewed' once the diff stops matching the original comparison.",
  "disposition": "census"
}

{
  "id": "P14-C-043",
  "name": "Momentic",
  "category": "verification",
  "source_url": "https://www.momentic.ai/docs",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Momentic is an AI-driven end-to-end testing platform for web, iOS, and Android: 'Write tests in natural language, run them anywhere.' AI agents convert plain-language descriptions into 'reliable, repeatable tests stored as readable YAML files in your codebase', which the docs frame as 'the verification layer for your application'. Relevant to Actionist because tests-as-committed-YAML means a generated capability could ship with its own generated verification artifact reviewable in the same PR. CLI runs 'on your laptop, in a CI pipeline, on a cloud agent sandbox, and so on', with example workflows for GitHub Actions, CircleCI, and Bitrise.",
  "attribution_granularity": "endpoint",
  "required_metadata": "Natural-language test descriptions compiled to YAML committed alongside source; CLI invocation in the pipeline. Cloud dashboard adds 'run viewing, analytics over time, an AI-maintained knowledge base, test quarantining, and enterprise features'.",
  "rollback_signal": "gate (unverified) — CI integration is documented but 'Nothing here describes deployment gating, required status checks, or blocking releases on failures'; whether a failing run halts a deploy depends on the customer's own pipeline configuration. UNVERIFIED.",
  "production_evidence": "none_found",
  "limitations": "Gating behavior not documented on the page examined. Test quarantining implies some failures can be excluded from counting, which weakens the gate unless governed. Pricing/licence not examined in this pass. Attribution is to a failing user journey, not to a component.",
  "disposition": "census"
}

{
  "id": "P14-C-044",
  "name": "Rollbar (deploy tracking / suspect deploy)",
  "category": "observability",
  "source_url": "https://docs.rollbar.com/docs/deploy-tracking",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Rollbar attributes an error to a deploy via a documented heuristic it calls Suspect Deploy, defined as either 'The last deploy prior to the first occurrence of the error' when the item was never resolved, or 'The last deploy prior to the reactivation of the error' when it had been resolved before. Deploy records capture 'Target environment' and 'Code version (typically a Git SHA or a version number)', plus start/finish time, status, deploying user, and — with a repo connected — a 'List of commits included'. Valuable as an explicitly-labelled heuristic: Rollbar states candidly that 'We are planning to improve our suspect deploy algorithm in the future to improve its accuracy.'",
  "attribution_granularity": "deploy",
  "required_metadata": "Deploy notification is NOT automatic: 'you will need to send API calls from your CICD tool to the Rollbar API to notify the platform of your deploy actions. They will not be detected automatically.' Requires environment and code version (Git SHA) per deploy, plus a connected git repository for commit-level listing.",
  "rollback_signal": "alert_only — nothing indicates deploy tracking triggers or drives a rollback. The only automated action described is optional item resolution on deploy.",
  "production_evidence": "none_found",
  "limitations": "Suspect Deploy is temporal, not causal — it is last-deploy-before-first-occurrence, which in a composed app deploying multiple capabilities independently will frequently blame the wrong capability. This is exactly the failure mode Actionist must avoid, and it is the clearest evidence in the survey that deploy-time correlation alone is insufficient for per-capability attribution. Deploys reported as 'started' that do not transition are set to 'timed_out' (default 60 min). RQL/version-query capability not covered on this page (UNVERIFIED).",
  "disposition": "census"
}

{
  "id": "P14-C-045",
  "name": "Vercel Runtime Logs",
  "category": "observability",
  "source_url": "https://vercel.com/docs/logs/runtime",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Vercel provides deploy-linked, route-linked, and invocation-linked error attribution with NO customer instrumentation required — the platform supplies the identifiers because it owns the runtime. Filterable/searchable fields include route ('The route pattern defined in your code (e.g., /blog/[slug])'), requestPath, requestType (api, ssr, isr, ppr, rsc, cron), level (warning, error, fatal), resource (function, middleware, cache, rewrite, redirect), host, deployment, deploymentId ('The unique identifier of your deployment'), status, requestId, environment (production or preview), branch ('The git branch associated with the deployment'), sessionId, traceId, and invocationId ('The unique identifier for a specific function invocation'). Log details include Function metadata ('function name, location, runtime, duration, memory usage, and start type'), Deployment metadata ('id, environment, and branch'), an Events timeline, and 'Outgoing Requests: Sub-requests made during the function execution'. This is the strongest zero-instrumentation attribution surface in the survey and directly models the case where Actionist hosts a capability as a function.",
  "attribution_granularity": "deploy",
  "required_metadata": "None from the customer for the platform-supplied identifiers — deploymentId, branch, route, requestId, invocationId, traceId are emitted by Vercel itself. Structured application logs are an optional enhancement. Requires the Runtime Logs permission.",
  "rollback_signal": "alert_only — logs are an observability surface; Vercel Instant Rollback is a separate product (already covered by P14-C-003). No automatic rollback driven from log signal is documented here.",
  "production_evidence": "none_found",
  "limitations": "Retention is the binding constraint and is plan-gated: Hobby 1 hour, Pro 1 day, Pro with Observability Plus 30 days, Enterprise 3 days, Enterprise with Observability Plus 30 days. Hard volume caps: 'The maximum number of logs is 256 lines per request', 256 KB per line, 1 MB total per request — a chatty composed capability can self-truncate its own evidence. Only covers Vercel Functions, Routing Middleware, and cache-serving static requests; full static logs need Log Drains. Attribution stops at the function/route boundary — a fault inside a called donor API appears only as an Outgoing Request, not as an attributed component.",
  "disposition": "census"
}

{
  "id": "P14-C-046",
  "name": "Elastic APM (service map)",
  "category": "observability",
  "source_url": "https://www.elastic.co/docs/solutions/observability/apm/service-map",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Elastic derives topology purely from traces: 'Service Maps rely on distributed traces to draw connections between services.' The docs are unusually explicit about the failure mode when the contract is not met — 'if a service isn't instrumented, or a traceparent header isn't being propagated to it, distributed tracing will not work, and the connection will not be drawn on the map.' This is the clearest first-party statement in the survey that trace-context propagation is the load-bearing requirement for cross-component attribution. Node shapes encode the distinction between owned and external components: circles are 'Instrumented services', diamonds are 'Databases, external, and messaging' typed by span.type and span.subtype. Errors elsewhere in Elastic APM 'are grouped based primarily on the stack trace, so you can identify new errors as they appear.'",
  "attribution_granularity": "dependency",
  "required_metadata": "APM agent or OpenTelemetry instrumentation in every component, AND traceparent header propagation across every boundary — without propagation the edge simply does not exist. For OpenTelemetry users the docs advise setting the deployment.environment resource attribute, which 'maps to the service.environment field that populates the environment selector'; omitting it collapses all environments into 'unset'. Distinct service names per component are needed because 'you have two or more services, in separate environments, but with the same name' is called out as the ambiguity case.",
  "rollback_signal": "alert_only — the map links out to traces, logs, alerts, and SLOs; no deploy gate documented.",
  "production_evidence": "none_found",
  "limitations": "Uninstrumented components are invisible as connections — the map silently omits them rather than flagging a gap, which for a composed app means an unattributed capability looks like no capability. Anomaly overlay requires machine learning jobs to be active. Service identity collisions across environments must be resolved by the environment attribute.",
  "disposition": "census"
}

{
  "id": "P14-C-047",
  "name": "Datadog Error Tracking",
  "category": "observability",
  "source_url": "https://docs.datadoghq.com/error_tracking/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "'Error Tracking simplifies debugging by grouping thousands of similar errors into a single issue', where an issue is 'an aggregation of error data that provides insights' including 'How many users have been impacted', 'When the error first occurred', and — the load-bearing claim — 'Which commit probably caused the error'. Errors are captured 'across your web, mobile, and backend applications' via Browser/Mobile SDK or ingested from Logs, Traces, and RUM events. Monitors can be set 'on error tracking events, such as high error volume or new issues'.",
  "attribution_granularity": "commit",
  "required_metadata": "Instrumentation via Browser SDK, Mobile SDK, or ingestion from Logs/Traces/RUM. Specific requirements for commit attribution are NOT documented on this page. UNVERIFIED: the fingerprinting algorithm, the grouping attributes, and service/version attribution are all absent from this page — 'Service and version attribution are not mentioned anywhere on this page', despite being standard Datadog tagging concepts.",
  "rollback_signal": "alert_only — monitors on error volume or new issues; no rollback.",
  "production_evidence": "none_found",
  "limitations": "Commit attribution is hedged in Datadog's own wording ('probably caused') and the mechanism is unspecified on this page — a marketing-adjacent claim rather than a documented mechanism, in contrast with Sentry suspect commits (P14-C-025) where the blame algorithm is spelled out. 'Feature availability varies by origin' — e.g. Exception Replay is APM-trace only. Recorded with this caveat deliberately: the parent lane should not rank Datadog commit attribution alongside Sentry's without stronger evidence.",
  "disposition": "census"
}

{
  "id": "P14-C-048",
  "name": "Rootly",
  "category": "incident",
  "source_url": "https://docs.rootly.com/",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "Rootly positions itself as 'The all-in-one AI platform for on-call, incident response, status pages, and post-incident learning', with alerts 'ingested, deduplicated, grouped, and routed to the right responder the first time'. Catalog sync is referenced in an August 4 2026 changelog entry ('Sync your catalog, and mute pages during Alert storms'). Configuration is available as code via a Terraform provider ('Manage Rootly as code, versioned and reviewed') and a full API.",
  "attribution_granularity": "service",
  "required_metadata": "UNVERIFIED from the page examined. The homepage 'doesn't document how services, components, or ownership relationships are modeled — nor how ownership feeds into routing decisions'. Catalog data appears to be syncable from external sources but the schema was not established in this pass.",
  "rollback_signal": "alert_only — pages a responder; no deploy control.",
  "production_evidence": "none_found",
  "limitations": "Only the documentation homepage was retrieved, so the ownership model is unestablished. Recorded at low evidence depth deliberately; do not rank against PagerDuty or incident.io on mechanism without fetching the catalog pages via the docs.rootly.com/llms.txt index. Migration guides exist for Opsgenie and PagerDuty.",
  "disposition": "census"
}

{
  "id": "P14-C-049",
  "name": "FireHydrant",
  "category": "incident",
  "source_url": "https://docs.firehydrant.com/docs/service-catalog",
  "observed_date": "2026-08-27",
  "evidence_class": "first_party_docs",
  "claim": "UNVERIFIED. The target page 'Service Catalog & Change Events' returned only navigational boilerplate — a frontmatter timestamp, a pointer to https://docs.firehydrant.com/llms.txt, and the heading, with no substantive content on ownership modeling, service dependencies, or component-based routing. Recorded so the parent lane knows this vendor was attempted and where to resume, not as a finding. The page title itself ('Service Catalog & Change Events') is suggestive of change-correlation capability worth a follow-up fetch.",
  "attribution_granularity": "none",
  "required_metadata": "unknown — not established",
  "rollback_signal": "unknown — not established",
  "production_evidence": "none_found",
  "limitations": "Docs page returned no content through WebFetch; the .md suffix trick and the llms.txt index are the documented alternate routes and were not exercised in this pass due to scope. Treat as an open gap, not as a negative finding about the product.",
  "disposition": "excluded"
}