Tygart Media

Tag: Developer Reference

  • The 5-Layer OpenRouter Mental Model: Org, Workspace, Guardrail, Key, Preset

    The 5-Layer OpenRouter Mental Model: Org, Workspace, Guardrail, Key, Preset

    The OpenRouter hierarchy in one sentence: Organizations contain Workspaces, Workspaces enforce Guardrails on API Keys, Keys call Presets, and Presets bundle prompts and models. Every operational decision you’ll ever make on the platform lives at exactly one of those five layers. Confuse them and you’ll spend hours looking for settings that live somewhere other than where you think.

    This is a companion to our OpenRouter operator’s field manual. The field manual covers why we use the platform and how it fits a fortress stack. This deep dive covers the mental model itself — the five-layer hierarchy that makes everything else legible.

    Why this matters before anything else

    OpenRouter’s UI presents a flat menu. The actual product is a hierarchy. Every operational decision you’ll ever make — who pays, what’s allowed, who’s allowed to call what, which model gets used — lives at exactly one of five layers. Get the layers wrong and you’ll wire your stack against the wrong nouns.

    The five layers, top to bottom: Organization → Workspace → Guardrail → API Key → Preset.

    Here’s what each one actually does and when you should care.

    Layer 1: Organization

    Sovereign billing. Sovereign member context. The top of the world.

    Each Organization has its own balance, its own billing details, and — critically — its own member roster. The catch: personal orgs don’t expose Members management. If you want to add teammates, you need a non-personal org.

    In our case we run two: a personal org tied to our primary email, and a Tygart Media org for agency operations. The personal org has 48 API keys and a working balance. The Tygart Media org is empty so far. Members management is the reason it exists.

    When to think about this layer: when you’re deciding whether to operate as an individual or as a team. If you’re solo and plan to stay solo, one personal org is fine forever. The moment you bring on a collaborator who needs their own keys and their own observability slice, you need a non-personal org.

    The mistake to avoid: running an agency out of a personal org. You’ll hit member-management limits at the worst possible time.

    Layer 2: Workspace

    Segmented guardrail, BYOK, routing, and preset domains inside an organization.

    By default, every org gets one Default Workspace. Most accounts never think about this layer. The moment you operate across multiple businesses with different data policies, multiple workspaces become valuable.

    Example: a healthcare client’s data should never touch first-party Anthropic, only Bedrock or Vertex. A consumer comedy site can use any provider. A B2B SaaS client wants Zero Data Retention enforced on every call. Three different fortress postures. Three workspaces.

    Each workspace gets its own Guardrail config, its own BYOK provider keys, its own routing defaults, and its own preset library. Keys created in one workspace can’t see resources in another.

    When to think about this layer: when you have two or more clients with materially different data policies. If everything you do has the same posture, one workspace is fine.

    The mistake to avoid: assuming workspace segmentation is a security boundary. It isn’t, exactly — it’s a policy boundary. Someone with org-level access can move between workspaces freely. Workspaces are for organizing intent, not for isolating threats.

    Layer 3: Guardrails

    The actual enforcement layer. Four categories, all configurable per workspace, all unconfigured by default.

    Budget Policies are the most useful and the most underused. Set a credit limit in dollars and a reset cadence (Day, Week, Month, Year, or N/A). Hit the limit and calls fail until the cadence resets. This is your protection against the runaway loop that drains a balance overnight.

    Model and Provider Access is where data-policy posture lives. Toggles for Zero Data Retention enforcement, Non-frontier ZDR, first-party Anthropic on or off (with Bedrock and Vertex always staying available), first-party OpenAI on or off (Azure stays), Google AI Studio on or off (Vertex stays), and three categories of paid and free endpoints with different training and publishing behaviors. There’s also an Access Policy mode (Allow All Except is the useful one) with explicit Blocked Providers and Blocked Models lists. The live Eligibility view shows you which providers and models are actually callable given your current policy.

    Prompt Injection Detection runs regex-based detection on inbound prompts. OWASP-inspired patterns. Four modes: Disabled, Flag, Redact, or Block. Free and adds no measurable latency. Worth enabling on every workspace that touches user input.

    Sensitive Info Detection runs pattern matching on prompts and completions. Built-in patterns for Email, Phone, SSN, Credit Card, IP address, Person Name, and Address. The latter two add latency. Custom regex patterns supported. A sandbox to test patterns before deploying. Useful for any workspace that processes customer data.

    When to think about this layer: every workspace, day one. Default-unconfigured is not a safe state. Set a budget cap before you do anything else.

    The mistake to avoid: treating Guardrails as something you’ll get to “later.” Later is after the runaway loop has drained the balance.

    Layer 4: API Keys

    Per-agent identity. Each key has its own credit cap, its own reset cadence, and its own guardrail overlay.

    The mental model that matters: one autonomous behavior, one key. When a scheduled task starts hemorrhaging tokens, the cap on its key contains the damage. The other 47 keys keep working.

    Our 48-key distribution is instructive. One testing key has spent $83.26. One development key has spent $33.05. The remaining 46 keys have collectively spent less than $120. That’s the shape of real AI operations: a few keys do most of the work, and a long tail barely moves the needle. Per-key caps make that distribution visible and bounded.

    API keys also carry the BYOK relationship. A bring-your-own provider key can be pinned to specific API keys, meaning specific agents. That lets you route a high-volume internal agent through a discounted enterprise contract while letting one-off testing keys fall through to OpenRouter’s pooled pricing. We cover this in depth in BYOK on OpenRouter.

    When to think about this layer: when you create any new autonomous behavior. New behavior, new key, new cap. No exceptions.

    The mistake to avoid: sharing one key across all your services. The first runaway loop will be the last thing that one key ever does, and the blast radius will be everything else that depended on it.

    Layer 5: Presets

    Versioned bundles of system prompt, model, parameters, and provider configuration. Called as "model": "@preset/your-preset-name" in any API call.

    Three tabs per preset: Configuration (the actual bundle), API Usage (how it’s been called), and Version History (every change, rollback-able).

    This is the closest OpenRouter comes to a software release artifact. You can ship a preset, test it in chat, version it, and roll back if v2 turns out to be worse than v1. Code that calls the preset stays the same; only the preset content changes.

    For autonomous behavior systems this is the unlock. A behavior’s behavior — its prompt, its model choice, its temperature — becomes a thing you can version and review like code, without touching the code that calls it. Promotion ledger says a behavior is graduating from one tier to the next? You publish a new preset version with tighter constraints and the calling code never changes.

    When to think about this layer: the moment you have any system prompt that’s used in more than one place, or that you’ll want to refine over time. If you’ve never copy-pasted a system prompt between two scripts, you don’t need presets yet.

    The mistake to avoid: putting the system prompt in the calling code. Every prompt update becomes a deploy. With presets, prompt updates become config changes.

    Putting the layers together

    Here’s the mental model in one sentence: Organizations contain Workspaces, Workspaces enforce Guardrails on Keys, Keys call Presets, Presets bundle prompts and models.

    If you walk into OpenRouter looking for a setting and you can’t find it, ask which of the five layers it should logically live at. The answer almost always tells you where to look.

    If you’re building a new integration, start at the bottom. Pick a model. Build a preset around it. Create a dedicated key with a tight budget cap. Sit that key under a workspace with sensible guardrails. The organization is just the billing wrapper.

    The whole point of the hierarchy is that each layer constrains the one below it. The organization caps the workspace. The workspace caps the keys. The keys cap the presets they can call. Errors propagate up; permissions cascade down. That’s the model. Everything else is UI.

    Frequently asked questions

    What are the five layers of OpenRouter?

    Organization, Workspace, Guardrails, API Keys, and Presets. Organizations handle billing and members. Workspaces segment policy domains. Guardrails enforce budget, provider access, prompt injection, and sensitive info rules. API Keys are per-agent identity with per-key caps. Presets are versioned bundles of system prompt, model, and parameters.

    Do I need multiple Workspaces in OpenRouter?

    Only if you operate across businesses with materially different data policies. A single Default Workspace is fine for most accounts. The moment a healthcare client requires Bedrock-only access while a consumer client can use any provider, workspace segmentation becomes valuable.

    What is the right way to use OpenRouter Presets?

    Treat them like software release artifacts. Bundle the system prompt, model, parameters, and provider config. Version every change. Test new versions in chat before promoting. Code that calls the preset stays the same; only the preset content evolves. This lets you refactor prompt behavior without redeploying.

    Are OpenRouter Workspaces a security boundary?

    No. They’re a policy boundary, not a security boundary. Someone with organization-level access can move between workspaces freely. Use workspaces to organize intent and enforce different fortress postures across clients — not to isolate threats from each other.

    What happens if I don’t configure OpenRouter Guardrails?

    By default every workspace has zero enforced budget cap, zero provider restrictions, and zero PII filtering. That’s fine for prototyping. It’s not fine for production. Set a budget cap on every workspace as the first action. The other three guardrail categories you can configure as you scale.

    See also: The Multi-Model AI Roundtable: A Three-Round Methodology for Better Decisions · What We Learned Querying 54 LLMs About Themselves (For $1.99 on OpenRouter)

  • Claude Code managed-settings.json: The Org-Wide Policy File Most Teams Skip

    Claude Code managed-settings.json: The Org-Wide Policy File Most Teams Skip

    Last week I wrote about the three-file split every team should set up in their repo: CLAUDE.md, .claude/settings.json, and .claude/settings.local.json. That gets a team to a sane shared baseline. It does not stop a single engineer with admin rights on their laptop from disabling every guardrail you wrote.

    If you are deploying Claude Code to more than a handful of engineers — anyone past Series B, anyone regulated, anyone whose CISO has asked a single pointed question about AI tooling — repo-level settings are insufficient. The control you want is managed-settings.json, and most teams I talk to either do not know it exists or have not deployed it.

    Where managed-settings.json Actually Lives

    Claude Code reads settings in a strict precedence order. Managed settings sit at the top and cannot be overridden by anything a user does in their repo, their home directory, or their environment. The file location depends on the OS:

    • macOS: /Library/Application Support/ClaudeCode/managed-settings.json
    • Linux / WSL: /etc/claude-code/managed-settings.json
    • Windows: C:\Program Files\ClaudeCode\managed-settings.json

    You push the file via whatever you already use to manage developer machines. On macOS that is MDM — Jamf, Kandji, Mosyle. On Windows it is Group Policy Preferences. On Linux fleets, your config management tool of choice — Ansible, Chef, whatever survived your last platform team rewrite. The file does not need to be created by Claude Code itself. It just needs to be present at the path above, owned and writable only by an admin account, and readable by the user running claude.

    The One Rule That Earns Its Keep: permissions.deny

    Of every field in managed-settings.json, the one that pays for the entire deployment effort is permissions.deny. Deny rules at the managed-settings tier take effect regardless of any allow or ask rules at lower scopes. A user cannot grant themselves permission to do something an admin has denied — not in their project settings, not in their personal settings, not via a one-time CLI flag.

    Concretely, here is a minimum-viable managed file for a team that wants to stop the obvious foot-guns:

    {
  "permissions": {
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(rm -rf /*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./**/credentials*)",
      "Read(./**/*secret*)"
    ]
  }
}

    That blocks Claude from curl-ing arbitrary URLs (the most common vector for accidental data exfiltration in agentic loops), reading anything in an .env file, and deleting filesystem roots in a Bash one-liner gone wrong. It does not stop legitimate work. It stops the long tail of “I didn’t realize it would do that.”

    The Drop-In Directory Is the Underrated Piece

    The single-file model breaks the moment you have more than one team contributing policy. Security wants curl blocked, platform wants kubectl delete blocked, the data team wants reads against the /data/prod/ mount blocked. Funneling all three through a single admin-owned file becomes a coordination tax.

    Claude Code supports a drop-in directory at managed-settings.d/ in the same parent directory as managed-settings.json. Files in that directory are merged alphabetically — same convention as systemd and sudoers.d. Layout looks like this:

    /Library/Application Support/ClaudeCode/
├── managed-settings.json          # base policy
└── managed-settings.d/
    ├── 10-security.json           # security team owns
    ├── 20-platform.json           # platform team owns
    └── 30-data.json               # data team owns

    Each team owns one file. They push their fragment through their own MDM channel without touching the others. Merge order is alphabetical, so the number prefix matters — later files override earlier ones for any overlapping keys, but permissions.deny rules always accumulate. Nothing a later file does can unblock something an earlier file denied.

    What Belongs in Managed Settings — and What Does Not

    Managed settings is a heavy hammer. Use it for things that must not be overridable. Everything else belongs in the repo’s .claude/settings.json, where engineers can iterate without filing a ticket.

    Belongs in managed:

    • Deny rules for credentials, network egress, destructive shell operations
    • Telemetry / opt-out flags if your contract with Anthropic requires training data opt-out
    • Default model if you have a real reason to pin — most teams should let repos choose
    • Audit log paths if you are forwarding to a SIEM

    Does not belong in managed:

    • Project-specific subagents or hooks (these live in the repo)
    • CLAUDE.md content (repo)
    • Allow rules — these are better as defaults at the repo scope, where engineers can adjust per-task

    Verifying the Policy Is Actually Active

    Pushing a config file is not the same as enforcing one. After deployment, run claude config list on a test machine and confirm the managed entries show up. Then attempt something the deny rule blocks — try a curl command, ask Claude to read an .env. The denial should be immediate and unambiguous, not a quiet skip. If a user can override it from their repo settings, the file is not at the right path or not readable by the user account running claude.

    Model Selection at the Org Level

    If you do pin a default model in managed settings — and I would argue most teams should not — read the model docs at docs.anthropic.com/en/docs/about-claude/models before writing the version string. Model identifiers change. As of this writing the workhorse is claude-sonnet-4-6, the flagship is claude-opus-4-7, and the fast option is claude-haiku-4-5-20251001. Hardcoding a model string in a managed file that nobody touches for six months is how you end up running last year’s model in production.

    Where This Approach Loses

    Managed settings cover the local Claude Code process. They do not cover the Anthropic Console, the Claude web app, or any MCP server an engineer connects to manually. If your threat model includes data leaving via the web app, managed settings on developer laptops are not the answer — the Enterprise plan’s org-level controls and SSO are. The two layers compose. Neither replaces the other.

    Managed settings also do nothing about an engineer who runs Claude Code on a personal machine outside MDM scope. That is a device management problem, not a Claude Code problem, and the fix is the same as it has always been: do not let unmanaged machines touch production code.

    The 30-Minute Rollout

    1. Pick one platform — start with whichever fleet is largest, usually macOS
    2. Write the minimum-viable managed-settings.json above
    3. Push it to one test machine via MDM, verify with claude config list
    4. Try three things the deny rules should block; confirm all three are blocked
    5. Roll to the rest of the fleet
    6. Set up the managed-settings.d/ directory so other teams can layer their own fragments without coordination

    The whole exercise is half a day of work for a platform engineer who already knows your MDM. The alternative is hoping every engineer reads the same Notion page about which commands not to run. Hope is not a security control.

  • How to Install and Deploy Claude Code in Production: The Complete Team Guide (May 2026)

    How to Install and Deploy Claude Code in Production: The Complete Team Guide (May 2026)

    Last refreshed: May 15, 2026

    Claude Code production deployment - install paths, CI integration, and team-scale cost controls
    Installing Claude Code is the easy part. Deploying it across a team in production is the part most guides skip.

    Most of the published guidance on installing Claude Code stops at “run npm install -g and you’re done.” That’s enough for a developer playing on a laptop. It is not enough for a team that wants to run Claude Code in production — in CI, in shared infrastructure, behind a firewall, with cost controls, and with the new Agent SDK billing model that takes effect June 15, 2026.

    This article is the production deployment guide. Triple-sourced against Anthropic’s own Claude Code documentation, the github.com/anthropics/claude-code-action repo, and Anthropic’s announced June 15 billing model. Verified May 15, 2026.

    The three install paths and which to pick

    Per Anthropic’s official Claude Code docs, there are three supported ways to install Claude Code. They produce the same underlying binary but make sense in different operational contexts.

    1. Standalone installer. A native installer for macOS, Windows, and Linux that drops the Claude Code binary in a system path. This is the cleanest install for individual developers — no Node.js required, no npm dependency, predictable upgrade behavior. Use this on workstations where the operator owns the machine.

    2. npm global package. npm install -g @anthropic-ai/claude-code. Requires Node.js 18 or later. Pulls the same native binary as the standalone installer through a per-platform optional dependency, then a postinstall step links it into place. Use this when you already manage developer tools through npm and want one less install path to track. Supported platforms: darwin-arm64, darwin-x64, linux-x64, linux-arm64, linux-x64-musl, linux-arm64-musl, win32-x64, win32-arm64.

    3. Desktop app. A desktop-class application distributed via .dmg on macOS and MSIX/.exe on Windows. This is the path most teams will deploy to non-developer staff, and it integrates with enterprise device management tools like Jamf, Kandji, and standard Windows MSIX deployment.

    If you are deploying across a team larger than a handful of developers, mix-and-match: standalone or npm for engineering workstations, desktop for everyone else.

    The npm install gotchas worth knowing before you ship

    Two things in Anthropic’s official docs are worth flagging because they will save you from a whole class of bug reports later:

    Don’t use sudo. Anthropic’s setup documentation explicitly warns against sudo npm install -g @anthropic-ai/claude-code. It can lead to permission issues and security risks. If you need a global install on a machine where your user can’t write to the npm prefix, fix the npm prefix first (point it at a user-writable directory) rather than escalating with sudo.

    Don’t use npm update for upgrades. The right command per Anthropic’s docs is npm install -g @anthropic-ai/claude-code@latest. npm update -g respects the original semver range and may not move you to the newest release. This trips up CI pipelines that try to keep Claude Code current via update; they will sit on a stale version forever.

    Production deployment considerations

    The single most important piece of context for a production Claude Code deployment in 2026: the billing model changes on June 15, 2026.

    Before June 15, Claude Code interactive sessions and claude -p non-interactive runs both draw from your normal subscription usage limits. Starting June 15, interactive Claude Code keeps using subscription limits as before, but claude -p and direct Agent SDK usage move to a separate per-user monthly Agent SDK credit pool ($20 Pro, $100 Max 5x, $200 Max 20x, $20-$100 Team, up to $200 Enterprise).

    For teams running Claude Code in CI, in cron jobs, in shell scripts, in GitHub Actions workflows — anywhere the trigger is automated rather than a human — this changes the economics. Plan capacity against the new credit pool, not the legacy shared subscription pool. Full breakdown in our Agent SDK Dual-Bucket Billing article.

    Three other production considerations:

    Network configuration. Behind a corporate firewall, you’ll need to allowlist Anthropic’s API endpoints, configure proxy settings, and potentially route through an LLM gateway. Anthropic’s network configuration documentation covers the specifics.

    Enterprise device deployment. Per Anthropic’s official docs, the desktop app distributes through standard enterprise tools — Jamf and Kandji on macOS via the .dmg installer, MSIX or .exe on Windows. If your IT team already has a deployment workflow for similar developer tools, Claude Code drops into it without anything special.

    API key management. If your team uses Claude Developer Platform API keys instead of (or alongside) subscription auth, manage them like any other production secret — vault them, rotate them, scope them per environment, never check them into source control. This becomes more important after June 15 because API key usage is the recommended path for sustained shared automation, and unintended sprawl gets expensive.

    Claude Code GitHub Actions: the team multiplier

    The fastest way to get team-level value from Claude Code is the official GitHub Actions integration. From Anthropic’s documentation and the public github.com/anthropics/claude-code-action repository:

    The setup command. The cleanest install is to run /install-github-app from inside Claude Code in your terminal. It walks you through installing the GitHub App, configuring the required secrets, and wiring the workflow file. Manual setup also works — copy the workflow YAML from Anthropic’s docs and add the ANTHROPIC_API_KEY secret to your repository settings — but the install command saves the assembly time.

    The interaction model. Once installed, mentioning @claude in a pull request comment or an issue triggers Claude Code to act on the context. Claude can analyze the diff, create new PRs, implement features described in an issue, fix reported bugs, and respond to follow-up comments — all while adhering to whatever conventions you’ve documented in your repository’s CLAUDE.md file.

    Three use cases worth separating clearly.

    • Automated code review. Claude Code reads the diff on every pull request and posts inline comments flagging potential issues, suggesting improvements, or checking for convention violations. Highest signal-to-noise when path-filtered to relevant code only.
    • Issue-to-PR automation. Tag @claude on a well-described issue and Claude Code opens a PR implementing it. Best for small, well-scoped changes; less useful for architectural work.
    • On-demand assistance. Reviewers tag @claude mid-PR to ask questions, request explanations, or get a second opinion before merging. The most defensible use case because it keeps a human in the decision loop.

    Pick the use case that matches your team’s actual bottleneck. Running all three at once on every PR is the fastest way to burn through your usage budget without proportionate value.

    Cost expectations at team scale

    Independent reports as of May 2026 put Claude Code GitHub Actions PR-review costs at roughly $15-25 per month for a team of 3-5 developers doing 10-15 PRs per week, billed against a Claude Developer Platform API key at Sonnet rates. That figure should be treated as directional — your actual cost depends on PR size, how many tools you’ve configured, model selection, and how aggressive your path-filtering is.

    Two cost controls that materially change the math:

    • Path filters. Trigger Claude Code only on file changes that actually need review. Skipping documentation, generated files, and lockfile-only PRs cuts the bill substantially.
    • Concurrency limits. GitHub Actions concurrency settings prevent Claude Code from running multiple instances against the same branch at once. Without this, force-pushes and rapid-fire updates can stack runs.

    If you are running Claude Code on every PR across an active team, you will hit Anthropic API rate limits. The mitigation is path filters, concurrency limits, and batching — none of which are speculative; they are documented patterns.

    The CLAUDE.md file is not optional

    Whatever your install path and whatever your use case, the single piece of project context that has the largest effect on Claude Code’s output is the CLAUDE.md file at the root of your repository. This is where you tell Claude Code what your project is, what conventions to follow, what tools are available, what to avoid, and what success looks like.

    If you skip it, Claude Code is reasoning from the files alone — useful but generic. If you write it, Claude Code is reasoning with your team’s context and your specific codebase rules. The difference shows up in the first ten minutes of use.

    A practical CLAUDE.md for a production team usually includes: the project’s purpose and stack, naming conventions and folder structure, testing requirements, lint and format rules, deployment considerations, what kinds of changes need human review, and explicit prohibitions (“never commit migrations directly to main”, “always update X when you change Y”). Keep it concise — verbose CLAUDE.md files inflate every per-turn token cost across the team.

    What to actually do this week

    1. Pick your install path per role (standalone or npm for developers, desktop for everyone else).
    2. Install Claude Code on one workstation and run through the quickstart end-to-end before rolling to the team.
    3. Write a real CLAUDE.md for your primary repository before anyone uses Claude Code on it. Even a 100-line version is far better than nothing.
    4. If you’re running anything automated, read the Agent SDK billing change before June 15.
    5. If you want team-level value, install the GitHub Actions integration — but pick one use case (code review, issue-to-PR, or on-demand help), not all three at once.
    6. Set path filters and concurrency limits in your workflow before you put Claude Code on every PR.

    Frequently Asked Questions

    What’s the difference between the npm install and the standalone installer?

    None functionally — both install the same native binary. The npm path is convenient if you already manage developer tools through npm. The standalone installer is cleaner if you don’t want a Node.js dependency. Both upgrade through their own mechanism.

    Why does Anthropic say not to use sudo with npm install?

    Per Anthropic’s official setup documentation, sudo with global npm installs can create permission issues and security risks. The recommended fix is to configure your npm prefix to a user-writable directory, then install without elevated privileges.

    How do I upgrade Claude Code installed via npm?

    Run npm install -g @anthropic-ai/claude-code@latest. Don’t use npm update -g — it respects the original semver range and may not move you to the latest release. This is documented in Anthropic’s setup guide.

    Does Claude Code work in CI/CD pipelines?

    Yes. The official GitHub Actions integration is the recommended path for GitHub-based workflows. For other CI systems (GitLab, CircleCI, Jenkins), the underlying tool is the Claude Agent SDK plus claude -p. Both move to the new Agent SDK monthly credit pool on June 15, 2026.

    How much does Claude Code GitHub Actions cost for a team?

    Independent reports as of May 2026 estimate $15-25/month for a 3-5 developer team running PR review on 10-15 PRs/week at Sonnet rates with a Claude Developer Platform API key. Actual cost varies with PR size, tool configuration, model selection, and path filtering aggressiveness.

    What’s the single biggest mistake teams make installing Claude Code?

    Skipping the CLAUDE.md file. Without it, Claude Code reasons generically against your codebase. With even a basic CLAUDE.md describing your conventions and constraints, output quality improves substantially across every interaction. It is the highest-leverage 30-minute setup task.

    Related Reading

    How we sourced this

    Sources reviewed May 15, 2026:

    • Anthropic Claude Code documentation: Set up Claude Code and Advanced setup at code.claude.com (primary source for install paths, npm gotchas, enterprise deployment patterns)
    • Anthropic Claude Code GitHub Actions documentation at code.claude.com/docs/en/github-actions (primary source for the GitHub Actions integration setup and use cases)
    • github.com/anthropics/claude-code-action public repository (primary source for the action’s interaction model)
    • Anthropic Help Center: Use the Claude Agent SDK with your Claude plan (primary source for the June 15, 2026 billing change)
    • Independent cost analyses (KissAPI, OpenHelm, Steve Kinney) for the team-scale cost estimates — Tier 2 confirming sources

    Cost figures and version specifics in this article are accurate as of May 15, 2026. Anthropic ships Claude Code updates frequently; the install paths and CLI commands are stable, but pricing and rate limits are the most likely figures to need re-verification.

  • LLMs.txt in 2026: The 4-Element Spec, The Robots.txt Pairing, and How to Verify Crawlers Are Reading It

    LLMs.txt in 2026: The 4-Element Spec, The Robots.txt Pairing, and How to Verify Crawlers Are Reading It

    If you publish an llms.txt file this week, no major model is going to fetch it tonight. That is the honest 2026 read on the spec — and yet the file is still worth shipping for narrow, specific reasons. This guide covers the 4-element specification published at llmstxt.org, the robots.txt pairing that actually controls AI crawler behavior right now, and a server-log filter you can run to verify whether anyone is reading the file you just shipped.

    What llms.txt actually is (and what it isn’t)

    llms.txt is a Markdown file served at the site root — /llms.txt — proposed by Jeremy Howard of Answer.AI on September 3, 2024. The spec at llmstxt.org defines four elements: a required H1 with the project or site name; a blockquote summary; zero or more Markdown content sections (no headings); and zero or more H2-delimited file-list sections containing annotated Markdown links to deeper content. That is the entire specification. There is no header convention, no schema requirement, no robots-style allow/deny syntax.

    What llms.txt is not: it is not a substitute for robots.txt, it is not an access-control mechanism, and as of May 2026 it is not consumed at inference time by ChatGPT, Claude, Gemini, Perplexity, or Copilot in any documented production system. Server-log audits across multiple independent practitioners show GPTBot, ClaudeBot, and Google-Extended do not request /llms.txt in meaningful volume during routine crawls.

    The realistic 2026 use case is developer tooling. AI coding assistants and IDE agents — Cursor, GitHub Copilot, Claude Code, and similar tools — retrieve docs in real time, and a curated llms.txt cuts token waste by pointing them at canonical Markdown sources instead of HTML-rendered pages bloated with nav and tracking. Companies like Anthropic, Stripe, Cursor, Cloudflare, Vercel, Mintlify, Supabase, and LangGraph ship llms.txt for that reason.

    The 4-element template — a working example

    Here is a real, valid llms.txt for a hypothetical SaaS docs site. Copy this structure, change the project name, and you have a shippable file in under 30 minutes:

    # Acme Analytics

> Acme Analytics is a self-hosted product analytics platform for SaaS teams. This file points AI assistants and IDE agents at canonical Markdown documentation, not the rendered HTML.

Authoritative Markdown sources for product, API, and SDK documentation. Use the `.md` variant of any docs page (append `.md` to the URL) for a clean, agent-friendly version.

## Getting Started

- [Quickstart](https://acme.example/docs/quickstart.md): 10-minute setup, install through first event.
- [Concepts](https://acme.example/docs/concepts.md): events, properties, identities, sessions — definitions and examples.

## API Reference

- [REST API Reference](https://acme.example/docs/api/rest.md): every endpoint, request/response schema, rate limits.
- [Webhook Reference](https://acme.example/docs/api/webhooks.md): payload contracts and retry behavior.

## SDKs

- [JavaScript SDK](https://acme.example/docs/sdk/js.md): browser and Node, including server-side rendering notes.
- [Python SDK](https://acme.example/docs/sdk/python.md): server-side ingestion patterns.

## Optional

- [Changelog](https://acme.example/docs/changelog.md): version history, breaking changes flagged inline.

    Two practitioner notes. First, the spec uses an “Optional” H2 as a soft signal — links under that heading can be skipped by aggressive token budgets. Second, the file is most useful when every linked URL has a parallel .md Markdown version. If your site is pure HTML, llms.txt without paired Markdown does little.

    The robots.txt pairing — this is what actually controls AI bots today

    The lever that meaningfully controls AI crawler behavior in 2026 is robots.txt with user-agent–specific rules. Anthropic publishes official documentation for three bots — ClaudeBot for training, Claude-User for user-initiated fetches, and Claude-SearchBot for search indexing — and confirms all three honor robots.txt. OpenAI runs GPTBot (training) and OAI-SearchBot (live ChatGPT search). Google’s AI training opt-out is the Google-Extended user-agent. Perplexity uses PerplexityBot.

    The two-bucket pattern most practitioner sites should ship: block training-only crawlers, allow search and user-initiated retrieval so your content can still be cited in answers.

    # Allow AI search and user-fetch traffic (citations, attribution)
User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# Block training-only crawlers
User-agent: ClaudeBot
Disallow: /

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# Standard search crawler — leave open
User-agent: Googlebot
Allow: /

Sitemap: https://example.com/sitemap.xml

    One operational caveat: robots.txt is policy, not enforcement. Anthropic, OpenAI, and Google have all publicly committed their named bots to compliance, but unnamed scrapers and residential-IP harvesters routinely ignore it. For sites with sensitive content, pair robots.txt with WAF or Cloudflare bot-management rules at the edge.

    Structured data still does more heavy lifting than llms.txt

    If your goal is AI citation rather than IDE-agent retrieval, structured data on the page itself moves the needle more than llms.txt. The minimum stack for any article you want cited: Article schema with named author and publisher, FAQPage schema on any post that answers a discrete question, and speakable markup on the answer paragraphs. These get parsed during normal HTML fetches by every major AI crawler — no separate file required.

    How to verify your llms.txt is actually being read

    Ship the file, then run this server-log filter weekly for 30 days. On any standard access-log format (nginx, Apache, or a Cloudflare log push), grep for requests to /llms.txt and break them down by user-agent:

    grep "GET /llms.txt" /var/log/nginx/access.log \
  | awk -F\" '{print $6}' \
  | sort | uniq -c | sort -rn

    What you will almost certainly see in May 2026: a steady trickle of human curl requests, the occasional IDE agent fetch tagged with a Cursor or VS Code user-agent, and effectively zero hits from GPTBot, ClaudeBot, or Google-Extended. That null result is itself the measurement — it tells you llms.txt is a developer-experience asset right now, not an AI-citation asset, and your investment should match that reality.

    The recommended 2026 rollout

    For most sites, the right sequence is: ship the robots.txt user-agent rules above first, because those are enforceable today and shape every AI crawler interaction. Add structured data to every article that competes for AI citation. Then publish llms.txt — under 30 minutes of work — for the IDE-agent and dev-tooling upside, with no expectation of immediate search lift. When OpenAI, Anthropic, or Google publicly confirm production llms.txt consumption, you are already in position.

  • Claude MCP in 2026: What Actually Changed and How to Configure It Without Wasting Tokens

    Claude MCP in 2026: What Actually Changed and How to Configure It Without Wasting Tokens

    Last refreshed: May 15, 2026

    If you set up Claude MCP six months ago and have not touched the config since, three things have changed underneath you: the recommended transport, how tools are loaded into context, and how teams share server configs. None of these are cosmetic. If you ignore them, you are leaving tokens, money, and stability on the table.

    This is the working Claude MCP setup I use in May 2026 — what the claude mcp add command actually does, which scope to pick, what the deprecation of SSE means in practice, and where Claude Code still falls short.

    The three-scope mental model

    Every MCP server you wire into Claude Code lives at exactly one of three scopes. Get this wrong and you will either leak credentials into git or wonder why your teammate cannot use the same database the AI just queried.

    • Local (default): the server is available only to you, only inside the current project. Config is written into your project’s entry inside ~/.claude.json. Good for project-specific servers like a dev database or a Sentry project key you do not want other repos to inherit.
    • User: the server is available to you across every project on your machine. Also stored in ~/.claude.json. This is where GitHub, search providers, and personal productivity servers belong.
    • Project: the server is written to a .mcp.json file at the repo root and shared with the whole team via git. Claude Code prompts for approval the first time a teammate opens the project — by design, because anyone who can push to the repo can wire a new server into your environment.

    When the same server is defined in more than one scope, Claude Code resolves it in this order: local beats project beats user beats plugin-provided. This is the part that bites people the most. If you have a “github” entry at user scope and someone adds a different “github” entry at project scope in .mcp.json, the project definition wins for that repo. Run claude mcp list when something behaves strangely.

    The commands you actually need

    The CLI is more useful than the docs make it look. Three commands cover ~90% of real setup work:

    # Add a remote HTTP MCP server at user scope (available everywhere)
claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic

# Add a local stdio server scoped only to this project
claude mcp add my-db -s local -- node ./scripts/db-mcp.js

# Share a server with your team via the repo's .mcp.json
claude mcp add my-server -s project -- node server.js

    The short flag is -s, the long is --scope. The -- separator is required for stdio servers because everything after it is treated as the literal command to spawn. Forget it and Claude Code will try to interpret your Node arguments as its own flags.

    SSE is dead. Use Streamable HTTP.

    If your MCP server documentation still tells you to use the sse transport, the documentation is stale. The MCP spec dated 2025-03-26 introduced Streamable HTTP and simultaneously deprecated HTTP+SSE. Through 2026, vendor after vendor has set hard cutoff dates — Atlassian’s Rovo MCP server keeps SSE around until June 30, 2026 and then drops it; Keboola pulled SSE on April 1; Cumulocity’s AI Agent Manager flipped to Streamable HTTP on May 8.

    Why this matters beyond a name change: SSE required Claude Code to hold a persistent connection to a single server replica, which broke horizontal scaling and made every transient network blip a reconnection drama. Streamable HTTP is stateless. Multiple replicas behind a load balancer just work. If you have flaky MCP connections in production, the first thing to check is whether the server is still on SSE.

    For new setups, use --transport http. The older --transport sse still functions but is on the deprecation path.

    Tool Search is the feature you should actually care about

    The single biggest change in how Claude Code uses MCP in 2026 is lazy tool loading via Tool Search. Older MCP clients dumped every tool schema from every connected server into the model’s context window at the start of every conversation. With ten servers wired up that could easily be 20,000+ tokens of overhead before you typed a single character.

    Tool Search inverts this. Claude Code keeps only the server names and short descriptions resident. When a tool is actually needed, it fetches that tool’s full schema on demand. Anthropic’s own documentation says this reduces tool-definition context usage by roughly 95% versus eager-loading clients. In practice that means you can run a serious MCP fleet — GitHub, Sentry, a database, a search provider, your internal API — without quietly burning through your context budget. The Sonnet 4.6 and Opus 4.7 1M-token context window does not save you here, because anything you let crowd the prompt is also being re-read on every turn.

    Companion feature: list_changed notifications. An MCP server can now tell Claude Code “my tool list changed” and Claude Code refreshes capabilities without a disconnect-reconnect dance. If you build your own server, emit this when you swap tool definitions and you save users a restart.

    What it still gets wrong

    Honest take: claude mcp list still does not surface scope information for every entry in a useful way — there is an open issue on the anthropics/claude-code repo asking for it (#8288 if you want to track). Project-scoped servers from .mcp.json have a separate history of not appearing in the list output (#5963) depending on how you opened the project. If you cannot find a server, check both ~/.claude.json and ./.mcp.json directly.

    The other rough edge is the project-approval prompt. The first time you open a repo with a new .mcp.json, Claude Code asks you to approve each project-scoped server. That is the right security default. It is also infuriating in CI or any non-interactive shell, where the prompt blocks the session. The current workaround is to bake the servers in at user scope on build agents so the project-scope approval never fires in CI. A cleaner non-interactive approval flow is the single most-requested fix I see in real teams.

    The setup I would run on a new machine today

    User-scope: GitHub, a code search server, and a single notes/Notion server. Project-scope in each repo’s .mcp.json: whatever database the project owns and whatever observability backend it reports to. Local-scope: anything experimental I am evaluating but do not want my team or my other repos to inherit.

    Pin --transport http on everything remote. Skip Desktop Extensions (.dxt) for anything you want versioned with the codebase — they are a Claude Desktop convenience, not a Claude Code primitive, and they hide the config from your team. Run claude mcp list when something is off and read .mcp.json directly when list is unhelpful.

    That is the whole working model. The pieces that matter — three scopes, Streamable HTTP, Tool Search — fit on a single screen. The pieces that have not caught up yet — list output, non-interactive approvals — are visible in the issue tracker and will move.

  • Claude Code Hooks: The Workflow Control Layer That Actually Enforces Your Rules

    Claude Code Hooks: The Workflow Control Layer That Actually Enforces Your Rules

    Last refreshed: May 15, 2026

    You’ve been there. You add a rule to CLAUDE.md — “always run prettier after editing files” — and Claude follows it, most of the time. Then it doesn’t. The formatter doesn’t run, the lint check gets skipped, and you’re back to reviewing diffs manually.

    Hooks fix this. Claude Code hooks are shell commands, HTTP endpoints, or LLM prompts that fire deterministically at specific points in Claude’s agentic loop. Unlike CLAUDE.md instructions, which are advisory, hooks are enforced at the execution layer — Claude cannot skip them.

    As of early 2026, Claude Code ships with 21 lifecycle events across four hook types. This article covers the two that matter most for daily workflow: PreToolUse and PostToolUse.

    How Hooks Work Architecturally

    Claude Code’s agent loop is a continuous cycle: receive input → plan → execute tools → observe results → repeat. Hooks intercept this loop at named checkpoints.

    Every hook is defined in .claude/settings.json under a hooks key. A hook entry has three parts: the lifecycle event name, an optional matcher (a regex against tool names), and the handler definition — either a shell command, an HTTP endpoint, or an LLM prompt.

    {
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write "$CLAUDE_TOOL_INPUT_FILE_PATH""
          }
        ]
      }
    ]
  }
}

    That’s it. Every file Claude writes or edits now auto-formats. No CLAUDE.md reminders, no hoping Claude remembers — the formatter runs on every single Write or Edit tool call, period.

    PreToolUse: Enforce Before Claude Acts

    PreToolUse fires before Claude executes any tool. Your hook receives the full tool call — name, inputs, arguments — and can return one of three signals:

    • Exit 0 → allow the tool call to proceed
    • Exit 2 → block the tool call; Claude receives your error message and adjusts
    • Exit 1 → hook error; Claude proceeds but logs the failure

    This makes PreToolUse the right place for guardrails. Here’s a real example: blocking npm in a bun project.

    #!/bin/bash
# .claude/hooks/check-package-manager.sh
# Blocks npm commands in projects that use bun

if echo "$CLAUDE_TOOL_INPUT_COMMAND" | grep -qE "^npm "; then
  echo "Error: This project uses bun, not npm. Use: bun install / bun run / bun add" >&2
  exit 2
fi
exit 0

    Wire it in settings.json:

    {
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/check-package-manager.sh"
          }
        ]
      }
    ]
  }
}

    Now when Claude tries npm install, the hook exits 2, Claude sees the error message, and it switches to bun install without you intervening. The correction happens in the same turn.

    Another production pattern: blocking writes to protected paths.

    #!/bin/bash
# Prevent Claude from modifying migration files already run in production
if echo "$CLAUDE_TOOL_INPUT_FILE_PATH" | grep -qE "db/migrations/"; then
  echo "Error: Migration files are immutable after deployment. Create a new migration instead." >&2
  exit 2
fi
exit 0

    PostToolUse: React After Claude Acts

    PostToolUse fires after a tool completes successfully. It can’t block execution, but it can provide feedback — and it can run any side-effect you need automatically.

    Auto-format every edit:

    {
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write "$CLAUDE_TOOL_INPUT_FILE_PATH" 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

    Run tests after code changes:

    #!/bin/bash
# Run affected tests after any source file edit
FILE="$CLAUDE_TOOL_INPUT_FILE_PATH"
if echo "$FILE" | grep -qE "\.(ts|js|py)$"; then
  if [ -f "package.json" ]; then
    npx jest --testPathPattern="$(basename ${FILE%.*})" --passWithNoTests 2>&1 | tail -5
  fi
fi

    Desktop notification on task completion:

    {
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification "Claude finished" with title "Claude Code"'"
          }
        ]
      }
    ]
  }
}

    Environment Variables Available to Hooks

    Claude Code exposes context about the triggering tool call through environment variables. The ones you’ll use most:

    VariableValue
    $CLAUDE_TOOL_NAMEName of the tool being called (e.g., Edit, Bash, Write)
    $CLAUDE_TOOL_INPUT_FILE_PATHFile path for Edit, Write, Read calls
    $CLAUDE_TOOL_INPUT_COMMANDShell command for Bash calls
    $CLAUDE_SESSION_IDCurrent session ID — useful for audit logging
    $CLAUDE_TOOL_RESULT_OUTPUTOutput of the tool (PostToolUse only)

    These are injected by Claude Code before your hook runs. You don’t configure them — they’re always there.

    The Model Question: Which Claude Runs Agentic Tasks?

    One practical consideration for hook-heavy workflows: the default model affects how well Claude responds to hook feedback. As of May 2026:

    • claude-opus-4-7 ($5/MTok input, $25/MTok output) — highest agentic coding capability; best at interpreting hook rejection messages and self-correcting without re-asking
    • claude-sonnet-4-6 ($3/MTok input, $15/MTok output) — strong balance of speed and reasoning; handles most hook-corrected flows well
    • claude-haiku-4-5-20251001 ($1/MTok input, $5/MTok output) — fastest; may require more explicit hook messages to course-correct reliably

    For workflows with complex PreToolUse guardrails — especially ones that provide long error messages with corrective instructions — Opus 4.7 handles the feedback loop most reliably. For simpler PostToolUse automation (formatters, notifications), model choice doesn’t matter; the hook runs regardless.

    To configure the model: export ANTHROPIC_MODEL=claude-opus-4-7 before launching Claude Code, or set it in your team’s .env.

    Hooks vs. CLAUDE.md: When to Use Each

    CLAUDE.md is the right place for context, preferences, and guidance — things you want Claude to know about your project. Hooks are the right place for behavior that must happen every time without exception.

    The practical test: if failing to follow the instruction costs you five minutes of manual cleanup, put it in a hook. If it’s a style preference or a reminder about architecture decisions, put it in CLAUDE.md. The two are complementary — you’ll likely end up with both in any mature project setup.

    A team that gets this right builds CLAUDE.md as documentation for Claude and hooks as the CI/CD equivalent for the agentic loop.

    Getting Started

    The fastest path to a working hook setup:

    1. Create .claude/settings.json in your project root if it doesn’t exist
    2. Add a PostToolUse hook wired to your formatter — this is low-risk and immediately valuable
    3. Test it by asking Claude to edit a file; the formatter should run automatically
    4. Add PreToolUse guardrails for any tool calls that have caused problems in the past

    The official hooks reference is at code.claude.com/docs/en/hooks — it covers all 21 lifecycle events, HTTP handler format, and the full JSON output schema for hook responses.

    Hooks are the difference between Claude Code as a powerful suggestion engine and Claude Code as a reliable automation layer. Once you have a PostToolUse formatter running on every edit, going back feels like working without version control.

  • For Everett Developers and Business Owners: What PUD’s Everett-Delta Transmission Line Means for Your Project’s Electrical Service

    For Everett Developers and Business Owners: What PUD’s Everett-Delta Transmission Line Means for Your Project’s Electrical Service

    The short version for developers: Snohomish County PUD’s new Everett-Delta 115-kV transmission line — 3.5 miles, connecting the Everett Substation to the Delta Switching Station near SR 529 / Marine View Drive — goes in service summer 2027. It adds the upstream transmission capacity PUD needs to connect the wave of new waterfront, downtown, and north-Everett developments at full load. If your building opens before summer 2027, confirm your electrical service agreement and any interim capacity arrangements with PUD now. If your opening is fall 2027 or later, you are in the planned capacity window.

    If you are developing, building out, or opening a business in Everett’s waterfront, downtown, or north-end corridor in 2026 or 2027, there is one piece of infrastructure that affects your electrical service capacity, your connection timeline, and your ability to run the systems your tenants and customers will expect. It is not a building permit. It is a power line.

    Snohomish County PUD’s new Everett-Delta 115-kilovolt transmission line is the upstream electrical capacity that the Millwright District, the downtown stadium, the Mosaic Apartments, and every other project in the corridor runs on. PUD held public open houses on May 7, 2026. Here is the business-owner and developer version of what you need to know. For the full project overview, see the complete Everett-Delta transmission line guide.

    The Capacity Problem the Line Solves

    Every large building in the waterfront corridor pulls electrical load. A 300-unit multifamily building with heat pumps, EV charging infrastructure, and commercial amenity spaces runs approximately 1 to 1.5 megawatts of peak demand. A restaurant with commercial kitchen equipment adds another 100 to 300 kilowatts per tenant. Stack the Millwright District Phase 2, Mosaic Apartments, the downtown stadium, and the Sage Investment Group conversion on top of projects already open at Waterfront Place — and you have a concentration of new load the existing north Everett transmission system was not designed to absorb.

    PUD’s language for why the line is being built is precise: “increasing electrical demand in the northern regions of the service territory” and “prevent the electric system from experiencing low voltage should local power be interrupted.” For a developer or building owner, that translates to: the existing infrastructure is operating with reduced headroom, and this line restores it.

    What Goes In Service and When

    The line connects PUD’s Everett Substation (west of I-5, between McDougall and Smith avenues) to the Delta Switching Station near SR 529 and West Marine View Drive. Construction is targeted to begin spring 2027. The line is planned to be in service by summer 2027, approximately six months of construction.

    The Practical Timeline Issue for Your Project

    If your building or commercial space is targeting an opening in 2026 or early 2027, you are opening before the Everett-Delta line is in service. For large-load projects — multifamily, high-load commercial anchors, destination restaurants with significant kitchen/HVAC load — confirm directly with PUD whether your project falls within the pre-line capacity envelope or whether there are interim arrangements needed.

    If your project is targeting a fall 2027 opening or later, you are timing well. PUD will have the upstream capacity in place and your service connection request goes into a queue that includes the new transmission headroom the Everett-Delta line creates.

    The Reliability Dimension

    Beyond raw capacity, the Everett-Delta line adds N-1 redundancy to the north Everett corridor. Once in service, PUD can reroute power around a failed line segment, maintaining voltage and continuity. For a restaurant, hotel, or high-density residential building where a power outage is a direct revenue and habitability event, this is a meaningful change in risk profile.

    The New Substation Implication

    PUD’s project documentation states the Everett-Delta line will “support at least one new substation in the Everett area” tied to the city’s 2044 Comprehensive Plan. The substation location has not been publicly announced. Developers planning projects in the 2028–2032 window should monitor PUD’s system improvements page for updates — the new substation’s location will directly affect which parts of the corridor have the most available service capacity after the line goes in. For the broader economic context, see the April 2026 Snohomish County market report.

    How to Stay Current

    PUD maintains a project page at snopud.com under System Improvements. For project-specific electrical service questions, PUD’s business services team handles large-load connection requests.

    Frequently Asked Questions for Developers and Business Owners

    Does the Everett-Delta line affect my electrical service connection timeline?

    For large-load projects opening before summer 2027, yes — confirm your connection capacity with PUD. For projects opening fall 2027 or later, the line adds upstream capacity that makes connection approvals more straightforward.

    When does construction begin and when is the line in service?

    Construction begins spring 2027; in service by summer 2027, approximately six months of construction.

    What load can existing north Everett transmission support now?

    PUD has not published a specific available capacity figure. Contact PUD’s business services team for a load study or capacity assessment for your specific project.

    Will there be construction disruption near Marine View Drive?

    Some work in the corridor is expected in spring-summer 2027. PUD will provide specific construction routing details as the project advances through permitting.

    Where is the new substation PUD mentioned?

    The location has not been publicly announced. PUD’s documentation states the line will support at least one new substation tied to Everett’s 2044 Comprehensive Plan. Watch snopud.com system improvements for updates.

  • RCP API Reference: Accessing the Framework Programmatically

    RCP API Reference: Accessing the Framework Programmatically

    The RCP REST API endpoint allows software developers, ESG platforms, and job management systems to programmatically access the full Restoration Carbon Protocol framework — all articles, emission factors, schema documentation, and article relationships — without scraping the site. This endpoint is part of the Tygart Media REST API and is publicly accessible without authentication.

    Base URL: https://tygartmedia.com/wp-json/tygart/v1/rcp

    Endpoints

    GET /wp-json/tygart/v1/rcp

    Returns the complete RCP framework index: all published articles with metadata, their relationship type within the framework, and links to full content.

    Request:

    GET https://tygartmedia.com/wp-json/tygart/v1/rcp
Accept: application/json

    Response structure:

    {
  "rcp_version": "1.0",
  "schema_version": "RCP-JCR-1.0",
  "last_updated": "2026-04-11",
  "framework_url": "https://tygartmedia.com/rcp/",
  "contact": "rcp@tygartmedia.com",
  "license": "CC BY 4.0",
  "articles": [
    {
      "id": 2481,
      "type": "introduction",
      "title": "Introducing the Restoration Carbon Protocol",
      "url": "https://tygartmedia.com/restoration-carbon-protocol-introduction/",
      "excerpt": "...",
      "tags": ["RCP", "GHG Protocol", "ESG", "Scope 3"]
    },
    ...
  ],
  "article_types": [
    "introduction", "regulatory", "job_type_guide",
    "data_standard", "commercial", "technical", "strategy"
  ]
}

    GET /wp-json/tygart/v1/rcp/schema

    Returns the full RCP-JCR-1.0 JSON Schema for a Job Carbon Report — the machine-readable data standard for per-job Scope 3 emissions records. This is the canonical schema endpoint for software developers implementing native RCP data capture.

    Request:

    GET https://tygartmedia.com/wp-json/tygart/v1/rcp/schema
Accept: application/json

    Response: Full JSON Schema Draft-07 object as published in the RCP JSON Schema v1.0 article.

    GET /wp-json/tygart/v1/rcp/factors

    Returns all RCP emission factors as structured JSON — vehicle emission factors, material factors, waste disposal factors, demolished building material factors, and the eGRID subregional table. This allows ESG platforms and carbon calculators to pull the current RCP factor set programmatically rather than hardcoding values.

    Request:

    GET https://tygartmedia.com/wp-json/tygart/v1/rcp/factors
Accept: application/json

    Response structure:

    {
  "factor_vintage": "EPA 2025 EF Hub, EPA eGRID 2023, EPA WARM v16, DEFRA 2024",
  "gwp_basis": "IPCC AR6 GWP-100 for refrigerants; IPCC AR5 for other gases",
  "last_updated": "2026-04-11",
  "transportation": {
    "units": "kg_co2e_per_mile",
    "factors": {
      "passenger_car_gasoline": 0.355,
      "light_truck_gasoline": 0.503,
      "light_truck_diesel": 0.523,
      "medium_truck_diesel": 1.084,
      "heavy_truck_unloaded": 1.612,
      "heavy_truck_loaded": 2.25,
      "hazmat_hauler_acm": 3.20,
      "medical_waste_hauler": 2.80
    }
  },
  "electricity": {
    "units": "kg_co2e_per_kwh",
    "national_average": 0.3497,
    "subregions": {
      "NYUP": 0.1101,
      "CAMX": 0.1950,
      "NEWE": 0.2464,
      "ERCT": 0.3341,
      "FRCC": 0.3560,
      "SRSO": 0.3837,
      "NYCW": 0.3927
    }
  },
  "waste_disposal": {
    "units": "tco2e_per_short_ton",
    "factors": {
      "mixed_cd_landfill": 0.16,
      "gypsum_drywall_landfill": 0.16,
      "gypsum_drywall_recycled": 0.02,
      "carpet_pad_landfill": 0.33,
      "carpet_pad_recycled": 0.05,
      "vinyl_lvp_landfill": 0.28,
      "vinyl_lvp_recycled": 0.08,
      "mixed_plastics_landfill": 0.25,
      "biohazard_incineration": 0.97,
      "biohazard_autoclave_landfill": 0.50,
      "acm_inert_transport_only": 0.018
    }
  },
  "materials_kg_co2e_per_unit": {
    "nitrile_glove_each": 0.0277,
    "n95_respirator_each": 0.05,
    "tyvek_suit_each": 0.52,
    "h2o2_antimicrobial_per_kg_active": 1.33,
    "lvp_flooring_per_m2": 5.2,
    "ceramic_tile_per_kg": 0.78,
    "ready_mix_concrete_per_kg": 0.13,
    "ldpe_sheeting_per_kg": 1.793
  },
  "refrigerant_gwp_ar6": {
    "R410A_blend": 2256,
    "R32": 771,
    "R454B_blend": 530,
    "R134a": 1530
  },
  "fuel_combustion": {
    "units": "kg_co2e_per_gallon",
    "gasoline": 8.887,
    "diesel": 10.21
  }
}

    GET /wp-json/tygart/v1/rcp/articles/{type}

    Returns articles filtered by framework type. Valid type values: job_type_guide, regulatory, data_standard, technical, strategy, introduction, commercial.

    Example — get all job type guides:

    GET https://tygartmedia.com/wp-json/tygart/v1/rcp/articles/job_type_guide

    Response: Array of article objects matching that type, with title, URL, excerpt, and job_types array (e.g., ["water_damage", "category_2", "category_3"]).

    Existing WordPress REST API — RCP Queries

    While the tygart/v1/rcp endpoints above are planned for v1.1 deployment, the existing WordPress REST API at /wp-json/wp/v2/ already supports filtered RCP queries using tag and category IDs.

    Get all RCP articles

    GET https://tygartmedia.com/wp-json/wp/v2/posts?tags=409&per_page=50
# Tag 409 = "RCP" — returns all 30 published RCP articles

    Get RCP articles by sub-type

    # Developer/technical articles only (tag 411 = Developer Reference)
GET https://tygartmedia.com/wp-json/wp/v2/posts?tags=409,411&per_page=20

# Regulatory articles (tag 369 = SB 253)
GET https://tygartmedia.com/wp-json/wp/v2/posts?tags=409,369&per_page=20

    Get a specific article with full content

    # RCP v1.0 Full Framework Document (post ID 2976)
GET https://tygartmedia.com/wp-json/wp/v2/posts/2976

# Returns: id, title, content.rendered, excerpt.rendered, 
#          link, slug, date, modified, tags, categories

    Get the RCP hub page

    GET https://tygartmedia.com/wp-json/wp/v2/pages?slug=rcp
# Returns the hub page at /rcp/ with full content and navigation structure

    Response fields available per post

    Field Type Description
    id integer WordPress post ID — stable across updates
    slug string URL slug — permanent, do not rely on for API queries (use ID)
    title.rendered string HTML-decoded article title
    content.rendered string Full article HTML — includes all tables, methodology, worked examples
    excerpt.rendered string Summary paragraph — suitable for search result snippets
    link string Canonical URL
    modified datetime Last updated — use to detect emission factor version updates
    tags array[int] Tag IDs — use 409 (RCP), 411 (Developer) for filtering

    RCP Tag ID Reference

    Tag ID Name Use
    409 RCP All RCP articles — primary filter for the full framework
    408 GHG Protocol All RCP articles (GHG Protocol aligned)
    366 Scope 3 All RCP articles (Scope 3 focused)
    77 ESG All RCP articles (ESG context)
    411 Developer Reference Technical articles: JSON schema, proxy guide, factor table, audit guide, software integration, 12 data points
    369 SB 253 Regulatory articles: SB 253, framework, FEMA, SBTi, CSRD

    Planned v1.1 API Enhancements (Roadmap)

    The following endpoints are targeted for deployment in RCP v1.1, pending implementation by the infrastructure team. The spec above defines the intended response format.

    • GET /wp-json/tygart/v1/rcp — Framework index with article type classification
    • GET /wp-json/tygart/v1/rcp/schema — RCP-JCR-1.0 JSON Schema as a clean API response
    • GET /wp-json/tygart/v1/rcp/factors — All emission factors as structured JSON with vintage metadata
    • GET /wp-json/tygart/v1/rcp/factors/{category} — Filtered factor sets (transportation, electricity, waste, materials)
    • GET /wp-json/tygart/v1/rcp/articles/{type} — Articles filtered by framework type

    Software vendors who want to implement the planned endpoints ahead of formal deployment, or who have implementation questions, contact: rcp@tygartmedia.com

  • RCP Audit Readiness Guide: How to Prepare Emissions Data for Third-Party Verification

    RCP Audit Readiness Guide: How to Prepare Emissions Data for Third-Party Verification

    Third-party verification of Scope 3 emissions data is no longer theoretical. California SB 253 requires limited assurance for Scope 3 emissions beginning in 2030. CSRD requires limited assurance for all emissions including Scope 3 from the date of initial reporting. GRESB added GHG data assurance as a newly scored metric in 2025. The direction of travel is clear: the per-job carbon data restoration contractors deliver to commercial clients will eventually be subject to external verification — not as a direct requirement on the contractor, but because the client’s verifier will examine the quality and traceability of the supplier data the client used to build their Scope 3 inventory.

    This guide explains what verifiers actually look for in Scope 3 contractor data, how the RCP framework satisfies those requirements by design, and what documentation you need to retain to be audit-ready when your clients’ verifiers come asking.

    The Two Levels of Assurance and What They Mean for Contractor Data

    Understanding assurance levels prevents confusion about what is actually being asked of you.

    Limited assurance is a negative assurance — the verifier is confirming they found nothing that makes the report materially wrong. It involves reviewing methodologies, sampling data points, and checking for internal consistency. For Scope 3 data from restoration contractors, a limited assurance engagement will typically review: whether the methodology is documented and consistent with the GHG Protocol, whether proxy values are sourced and labeled, and whether the total reported figure is internally consistent with the underlying calculation inputs.

    Reasonable assurance is a positive assurance — the verifier actively confirms the data is accurate. It involves re-performing calculations from source documents, testing internal controls, and in some sectors, site visits. For Scope 3 contractor data under reasonable assurance, verifiers will request the underlying source documents — GPS trip logs, waste manifests, purchase receipts — and verify that the calculation produces the reported number from those inputs.

    The practical implication: for limited assurance, methodology documentation and labeling of proxy data are sufficient. For reasonable assurance, you need the source documents. The RCP 12-point data capture standard is designed to collect exactly those source documents at the time of the job, making reasonable assurance retroactively possible without extra effort.

    The GHG Protocol’s Five Audit Principles — Applied to RCP Records

    The GHG Protocol Corporate Value Chain Standard specifies five principles that a Scope 3 inventory — and by extension, the contractor data that feeds it — must satisfy for assurance purposes. Understanding how RCP records satisfy each principle makes audit preparation straightforward.

    1. Relevance

    What verifiers check: Whether the emissions sources included reflect the actual emissions generated on behalf of the client, and whether any exclusions are documented and justified.

    How RCP satisfies this: The scope boundary section of the RCP Full Framework Document explicitly lists what is included and excluded, with justification for each exclusion. The job_type and damage_category fields in the RCP JSON schema ensure the correct emission domains are applied for each job type. No RCP-compliant record silently excludes a material emission source — exclusions must be documented in the data_quality.notes field.

    2. Completeness

    What verifiers check: Whether all material Scope 3 categories are covered and whether the reporting boundary is consistently applied across all jobs in the portfolio.

    How RCP satisfies this: The RCP portfolio summary covers all jobs at a client’s properties during the reporting period. The four GHG Protocol categories covered (Cat. 1, 4, 5, 12) are documented in the framework as the complete set of material categories for restoration work. A verifier can confirm completeness by checking that every invoiced job appears in the portfolio summary.

    3. Consistency

    What verifiers check: Whether the same methodology and emission factors are applied across all jobs, and whether year-over-year comparisons are valid.

    How RCP satisfies this: The schema_version field (“RCP-JCR-1.0”) ensures every record uses the same schema. The emission factor vintage is documented in the framework (“EPA 2025 EF Hub, EPA eGRID 2023, EPA WARM v16”). When CARB or EPA updates emission factors, the RCP patch version increments, creating a clear record of when methodology changed. Verifiers can request the emission factor table used and verify it matches the published RCP version for that reporting year.

    4. Transparency

    What verifiers check: Whether methodology is fully disclosed, proxy values are labeled, and the calculation can be reproduced from the disclosed inputs and factors.

    How RCP satisfies this: The data_quality section of every RCP Job Carbon Report explicitly lists which data points are primary and which are proxy-estimated. The calculation_method field in each domain section identifies whether primary or proxy methodology was used. The emission factors are published in the RCP Emission Factor Reference Table with source citations. A verifier provided with an RCP JSON record, the proxy value table, and the raw source documents can reproduce the reported number independently.

    5. Accuracy

    What verifiers check: Whether the quantification is systematic, consistent, and not materially biased toward over- or under-reporting.

    How RCP satisfies this: The proxy value hierarchy (primary > derived primary > job-specific proxy > national average proxy) ensures that the calculation uses the most accurate available data for each input. The data_quality section’s primary_data_points list lets verifiers assess what fraction of the total is based on primary data. The systematic use of EPA-sourced emission factors — not custom or proprietary factors — provides a defensible, auditor-recognized basis for every number.

    What Source Documents to Retain and for How Long

    The following source documents underpin each of the 12 RCP data points. Retain these at the job level, linked to the job ID, for a minimum of seven years. This covers the typical verification lookback period under CSRD (5 years) plus margin.

    Data Point Source Document to Retain Assurance Level Required
    1 — Vehicle log GPS trip export or odometer log with vehicle ID, date, start/end location, miles Reasonable assurance
    2 — Waste transport Disposal facility weight receipt or manifest with facility name, date, weight, material type Reasonable assurance
    3 — Equipment power source Job notes confirming building power or generator fuel purchase receipt Limited assurance
    4 — Chemical treatments Purchase order or supply requisition for chemicals used on this job, with quantities Limited assurance
    5 — PPE consumption Supply order by job or proxy rate table reference if job-specific data unavailable Limited assurance (proxy acceptable)
    6 — Containment materials Close-out notes with quantities or proxy rate table reference Limited assurance (proxy acceptable)
    7 — Debris volume Disposal facility weight receipt (see Data Point 2) or dumpster manifest Reasonable assurance
    8 — Disposal method/facility Disposal facility receipt naming the facility and disposal method Reasonable assurance
    9 — Demolished materials Demolition scope from job file (Xactimate estimate or written scope), photo documentation Reasonable assurance
    10 — Replacement materials Purchase orders or materials delivery receipts with quantities Reasonable assurance (if in scope)
    11 — Job classification Initial assessment documentation with damage category, class, and affected area Limited assurance
    12 — Job timeline Job management system record with start and completion dates Limited assurance

    How RCP Records Are Treated by Verifiers Under Limited vs. Reasonable Assurance

    When a property manager’s verifier reviews their Scope 3 inventory under limited assurance, they will typically sample a subset of vendor records — often 10–20% of the total by value — and check for: consistency with stated methodology, that proxy records are labeled as such, and that the calculation produces a plausible number given the stated activity. An RCP JSON record satisfies all three checks without additional preparation, because the schema enforces methodology documentation, proxy labeling is required in the data_quality section, and the calculation is transparent and reproducible.

    Under reasonable assurance, the verifier may specifically request source documents for the sampled records. This is where the seven-year document retention requirement becomes material. A contractor who can produce the disposal facility receipt, the GPS trip log, and the Xactimate estimate for a job from 18 months ago has converted a potential audit finding into a zero-question pass.

    The most common Scope 3 audit finding for contractor data is: proxy data used without documentation of why primary data was unavailable. The RCP data_quality.notes field is specifically designed to prevent this. Every proxy-based data point should have a note explaining why primary data was unavailable: “Vehicle mileage estimated from dispatch records — GPS fleet system not yet deployed” is a valid and audit-acceptable explanation. Silence is not.

    The Chain of Custody for RCP Data

    Verifiers are increasingly attentive to the chain of custody for supplier data — how data traveled from the source activity to the reported number in the client’s inventory. For RCP records, the chain of custody is:

    1. Source activity: Vehicle trip, equipment run, waste disposal event
    2. Source document: GPS log, manifest, purchase receipt
    3. Data entry: Job management system (Encircle, PSA, Dash, manual log)
    4. RCP calculation: Activity data × emission factor = kg CO₂e per domain
    5. RCP Job Carbon Report: JSON record with emissions summary and data quality metadata
    6. Client delivery: Email, ESG platform upload, or API transmission
    7. Client inventory: Aggregate Scope 3 figure in GRESB/CDP/SB 253 disclosure

    Each link in this chain should be documentable. When a verifier asks “how did this number get into the inventory?” you should be able to walk from step 1 to step 7 for any sampled job.

    Conducting Your Own Pre-Audit Review

    Before your clients face their first verified Scope 3 disclosure cycle, run a pre-audit review of your own RCP records. The GHG Protocol explicitly recommends that inventory preparers treat each verification cycle as a learning process. For restoration contractors, a practical pre-audit review involves:

    1. Pull the portfolio summary for your largest commercial client for the most recent year. Count the total jobs and total tCO₂e reported.
    2. Sample 5 jobs — pick 2 large, 2 medium, 1 small by affected area. For each, verify you can locate all 12 data point source documents.
    3. Check proxy labeling. For every job where a proxy was used, confirm the data_quality section identifies the proxy data points and the notes field explains why.
    4. Reproduce one calculation. Take one job record and manually calculate the emissions from the source documents. Verify it matches the reported total within rounding.
    5. Check version consistency. Verify all records in the portfolio used schema_version “RCP-JCR-1.0” and the same emission factor vintage. Mixed vintages require disclosure.
    6. Document your findings. A one-page internal review memo noting what you checked and what you found creates a quality control record that verifiers view favorably as evidence of internal controls.

    The Version Control Requirement

    If a Job Carbon Report is corrected after delivery — because a waste manifest weight was updated, a vehicle mileage was corrected, or a proxy value was replaced with primary data — the corrected record must be issued as a new version. The version increment convention for RCP Job Carbon Reports is appending a revision suffix to the job ID: JOB-2026-04847-R1, JOB-2026-04847-R2, etc. The data_quality.notes field must document what changed and why. The original record should be retained alongside the revision — verifiers may ask why a record was corrected.

    Assurance Standards Your Clients’ Verifiers Will Use

    Different verifiers use different professional standards for GHG assurance. The most common frameworks your clients’ verifiers will reference:

    • ISAE 3000: The International Standard on Assurance Engagements (Revised) — the dominant framework for GHG assurance in the EU and used by the Big Four accounting firms globally
    • ISO 14064-3: Specification with guidance for the validation and verification of GHG statements — widely used in the US and internationally
    • AA1000AS: AccountAbility Assurance Standard — common in voluntary sustainability reporting contexts
    • CSAE 3410: Canadian standard, referenced by SB 253 as an acceptable framework

    None of these standards create requirements that a contractor must meet directly — they govern how the verifier conducts the engagement. But understanding them helps you know what questions to expect if a client’s verifier contacts you directly about sampled records.

    Sources and References

  • How to Integrate RCP Data into Encircle, PSA, Dash, and Xcelerate

    How to Integrate RCP Data into Encircle, PSA, Dash, and Xcelerate

    The Restoration Carbon Protocol was designed from the start to be implemented by software, not filled out by hand. The 12 RCP data points map almost entirely to fields that restoration job management platforms already capture — or can capture with minimal configuration. This guide is a direct call to action to the restoration software industry: Encircle, PSA, Dash, Xcelerate, Albiware, Restoration Manager, and any platform serving restoration contractors. Here is exactly what RCP compatibility requires and how to implement it.

    The Business Case for Software Vendors

    Restoration platforms that implement RCP compatibility give their contractor customers a differentiator that commercial property managers will actively request. As California SB 253 Scope 3 reporting requirements come into effect in 2027 and GRESB, CDP, and CSRD pressure continues to build, commercial clients will increasingly require their restoration vendors to provide per-job carbon data. The contractor that can push a button and produce an RCP-compliant Job Carbon Report wins the commercial renewal. The platform that makes that button possible wins the contractor.

    RCP compatibility is also a concrete AI-era feature: it transforms job documentation from a liability tool into a value delivery mechanism. Every well-documented job becomes a carbon asset that the contractor can monetize with commercial clients.

    Platform-by-Platform RCP Compatibility Analysis

    Encircle

    Encircle’s strength is field documentation — photos, moisture readings, drying logs, contents inventories, and report generation. It is the platform closest to capturing the data RCP needs at the source.

    RCP Data Point Encircle Field / Location Implementation
    1 — Vehicle log Not currently captured natively Add custom “Vehicle Trips” section to job close-out form: vehicle type, fuel type, trip count, miles
    3 — Equipment power source Drying log / equipment log Add “Power Source” toggle (building power / generator) to equipment placement form. If generator, add fuel type and gallons fields.
    4 — Chemical treatments Notes / photo documentation Add structured chemical application form: product type, volume in liters, application area. Currently unstructured.
    5 — PPE consumption Not currently captured Add PPE close-out field to job form with unit counts by type. Can default to RCP proxy rates based on damage category/class.
    6 — Containment materials Contained loss setup photos (unstructured) Add structured containment log: poly sheeting meters, zipper door count, HEPA filter replacements.
    7, 8 — Waste log Not currently captured Add waste manifest section to close-out: waste type, weight (tons), disposal method, facility name. Manifest photo upload.
    9 — Demolished materials Scope of work / room sketcher Link demolition scope to material weight calculation. Encircle already captures sqft demolished; apply RCP weight-per-sqft table to produce weight by material type.
    11 — Job classification ✅ Damage category and class, job type, sqft — already captured No change needed. Map Encircle category/class fields directly to RCP job_identification fields.
    12 — Job timeline ✅ Start and completion dates — already captured No change needed. Direct mapping to RCP job_start_date and job_completion_date.

    RCP JSON export implementation: Encircle’s existing report generation engine can be extended to produce an RCP-JCR-1.0 JSON file as an additional report type at job close-out. The JSON structure maps directly to Encircle’s data model with the additions described above.

    PSA (Canam Systems)

    PSA is a full job management, CRM, and accounting platform with open API access. It integrates with Xactimate, XactAnalysis, Encircle, and Matterport. PSA’s open API makes it the platform most ready for RCP integration without UI changes.

    RCP Data Point PSA Field / Module Implementation
    1 — Vehicle log Job tasks / time tracking Add vehicle dispatch fields to job tasks: vehicle ID, fuel type, departure/return mileage. Or pull from GPS integration if enabled.
    4-6 — Materials and PPE Job expenses / purchase orders Map RCP chemical, PPE, and containment line items to job expense categories. Add RCP category tags to existing expense item types.
    7-8 — Waste log Job expenses / subcontractor Add waste disposal as structured expense type with weight, method, and facility fields. Currently tracked as cost, not as physical quantity.
    9 — Demolished materials Job scope / Xactimate import Parse Xactimate line items for demolition scope. Map Xactimate line item codes to RCP material types. Weight is derivable from sqft and material type.
    11-12 — Classification, timeline ✅ Job intake form — already captured Direct mapping. PSA damage type and class fields map to RCP job_type, damage_category, damage_class.

    API integration path: PSA’s open API allows an RCP calculation engine to pull job data at close-out, compute emissions, and POST the resulting RCP-JCR-1.0 JSON to a client-facing endpoint or ESG platform directly. This is the most powerful implementation path and requires no UI changes to PSA itself.

    Dash (Next Gear Solutions)

    Dash is a full restoration business management platform with Xactimate integration and strong insurance claims workflow support. Its equipment tracking and job financials modules are the primary RCP integration points.

    RCP Data Point Dash Module Implementation
    1 — Vehicle log Job scheduling / dispatch Add vehicle type, fuel type, and round-trip miles to dispatch records. GPS integration if available.
    3 — Equipment power source Equipment tracking Add “Power Source” field to equipment deployment record. Dash tracks equipment placement dates already — add power source and generator fuel log.
    9 — Demolished materials Xactimate integration Same as PSA — parse Xactimate line items for RCP material type mapping.
    11-12 — Classification, timeline ✅ Job type, dates — captured Direct mapping from Dash job record to RCP fields.

    Xcelerate

    Xcelerate focuses on operational efficiency and field capture with workflow management and daily checklists. Its customizable daily checklist system is the primary integration point for RCP data capture.

    The Xcelerate daily checklist can be configured to include RCP data fields at each technician check-in: vehicle mileage logged, equipment runtime hours, materials consumed. This captures data points 1, 3, 4, 5, and 6 as part of the existing technician workflow with no additional friction. At job close-out, waste and demolished materials fields complete the 12-point record.

    The Xactimate Integration Opportunity

    Xactimate is the dominant estimating platform across the restoration industry. Its line-item scope database defines what was removed and replaced on virtually every insurance-backed restoration job in the US. This creates a unique RCP integration opportunity: Xactimate line items can be mapped to RCP material types automatically.

    A partial Xactimate → RCP material type mapping:

    Xactimate Category RCP Material Type Weight Proxy
    DRY — Drywall remove and replace drywall_standard 2.2 lbs/sqft (½” standard)
    FLR — Carpet remove and replace carpet 0.75 lbs/sqft
    FLR — Vinyl / LVP remove and replace lvp_flooring 1.2 lbs/sqft
    INS — Insulation remove and replace insulation_fiberglass 0.5 lbs/sqft (batt, 3.5″)
    FRM — Framing remove and replace lumber_framing 1.5 lbs/lf (2×4 stud)

    A software vendor that implements this mapping can auto-populate RCP data points 9 and 10 directly from the Xactimate estimate on any job where an estimate exists — which is the majority of commercial losses. This is the single highest-leverage implementation step in the entire RCP software integration roadmap.

    The API Call Structure for RCP Data Exchange

    For platforms that want to push RCP data to a client-facing endpoint or ESG platform, the standard API pattern is:

    POST /api/rcp/v1/job-carbon-reports
Content-Type: application/json
Authorization: Bearer {api_key}

{
  "schema_version": "RCP-JCR-1.0",
  "job_identification": { ... },
  "emissions_summary": { ... },
  "transportation": { ... },
  "materials": { ... },
  "waste": { ... },
  "demolished_materials": { ... },
  "data_quality": { ... }
}

Response 201 Created:
{
  "record_id": "RCP-2026-04847",
  "status": "accepted",
  "validation_warnings": [],
  "client_notification": "sent"
}

    For ESG platforms that receive RCP data from multiple contractors (Measurabl, Yardi Elevate, Deepki, Atrius), the recommended intake pattern is a webhook endpoint that accepts POST requests with RCP-JCR-1.0 JSON bodies, validates against the published schema, and maps emissions totals to the platform’s Scope 3 category data model.

    RCP Compatibility Certification for Platforms

    Software platforms that implement RCP compatibility will be listed on the RCP-compatible platforms registry (forthcoming at tygartmedia.com/rcp). To qualify:

    1. Capture all 12 RCP data points (primary or proxy with documentation)
    2. Produce valid RCP-JCR-1.0 JSON output that validates against the published schema
    3. Label proxy-estimated data points in the data_quality section
    4. Notify Tygart Media at rcp@tygartmedia.com with a sample output record

    Compatibility certification is free. It is a recognition that the platform meets the RCP standard, not a paid endorsement.

    Sources and References