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.
Until Notion 3.4 part 2, working with database views via the API meant fetching the underlying database and replicating view logic in code. The new endpoints give direct programmatic access to view configurations — query a view, apply its filters server-side, modify its display properties, all via the API. For developers building agents and integrations, this removes a significant friction point.
What the new endpoints enable
What the new endpoints enable.
1. Query a view directly.
Fetch the rows a specific view shows, with the view’s filters and sorts already applied. Previously, you fetched the database and re-implemented filtering in client code. Now the server does it. 2. Read view configuration.
Inspect what a view’s filters, sorts, and column selections are. Useful for agents that need to understand what a view represents. 3. Modify view properties programmatically.
Update filters, sorts, or display settings via API. Useful for dynamic views that adapt based on agent context. 4. List views per database.
Enumerate all views attached to a database. Helpful for agents that need to discover the right view to query.
Three patterns this enables
Three patterns this enables.
1. View-driven agent context.
Instead of giving an agent the entire database and a complex prompt about filtering, point the agent at a pre-configured view. The view defines the context; the agent works with the filtered subset. 2. Dynamic view modification.
An agent that adjusts a view’s filter based on conversation. “Show me last week’s high-priority items” becomes a real query against a view, not a search across the whole database. 3. View-as-API.
Treat each view as a parameterized data endpoint. Builders can expose specific views to specific agents, controlling exactly what data the agent sees through the view definition.
Practical implementation notes
Practical implementation notes.
Fetching views: Use the database fetch tool first to discover view URLs. View URLs include the view ID after ?v=.
Multi-source databases: Views may apply to a specific source.
Permissions: API access to views inherits the database’s permission model.
Where this goes wrong
1. Treating views as static. Views can be modified by users in the UI. Agents that cache view configurations get stale. 2. Over-fetching. Querying a view is more efficient than fetching the database and filtering client-side. Migrate. 3. Confusion between views and data sources. Multi-source databases have both. Don’t mix the API parameters.
What to read next
Workers + External APIs, Workers in TypeScript, MCP, Designing Database Schemas for Autofill.
Workers reward a specific style of TypeScript: small, single-purpose, structured-input-and-output, well-typed. The constraints (30 seconds, 128MB, no state) push you toward this style automatically. Workers that hold up in production share patterns: typed input/output schemas, defensive HTTP calls with timeouts, structured error returns, no hidden side effects.
Five production patterns
Five production patterns for Workers.
1. Type your input and output.
Type strictly. The agent works against the schema. Schema drift breaks the agent silently. 2. Defensive HTTP with timeouts.
External API calls inside a 30-second budget need their own timeouts. A 25-second API call leaves 5 seconds for everything else. Set explicit fetch timeouts shorter than the Worker timeout. 3. Structured error returns instead of throws.
Throw inside a Worker and the agent gets opaque failure. Return structured error objects and the agent can reason about the failure and respond gracefully. 4. Idempotency where state matters.
Workers have no persistent state, but they can hit external systems that do. If the external call is non-idempotent (e.g., creates a record), include an idempotency key derived from input. Calling the Worker twice should produce one record, not two. 5. Approved domains as a deployment artifact.
Track domain approvals in code. When a Worker stops working in production, “did the approved domains change” is the first thing to check.
Three production failures to design around
Three production failures to design around.
1. The 30-second wall. Aim for under 5 seconds typical, under 15 worst case. Long calls fail under retry loads. 2. Silent domain blocks. A Worker calling a non-approved domain fails with an error that isn’t always obvious. Log every outbound destination. 3. Memory leaks via large responses. Don’t pull a 50MB JSON response into a 128MB Worker. Stream, paginate, or pre-filter at the source.
Testing strategy
Testing strategy.
Unit-test the Worker logic separately from the agent. Use mock HTTP. Then integration-test with the actual agent calling the Worker. The two test layers catch different bugs.
What to read next
Workers + External APIs, Notion AI Meets MCP, Workers for Agents foundation piece, Security Posture.
Building a skill that works on the first try is rare. Building a skill that works after three iterations is normal. The discipline is starting with a narrow scope, writing specific instructions, testing against real inputs, and tightening based on what fails. Most operators build skills that are too broad and too vague. The fix is the opposite of intuition — narrower, more specific, more bounded.
Step-by-step
Step-by-step: building your first Notion skill.
Step 1 — Pick the right first skill. Not the most ambitious one. The most repetitive one. “Weekly digest from project database” is a great first skill. “Generate our entire content strategy” is a terrible first skill. Step 2 — Write the instructions. Specific format. Specific sections. Specific length. Specific tone. “Summarize” produces variance; “Produce a one-page summary with these five sections in this order, max two sentences per section, in active voice” produces consistency. Step 3 — Bound the context. Which database does it read? Which pages? Which fields? Pin tightly. Expand only when needed. Step 4 — Test five times. Run the skill against five different real inputs. Look at outputs side by side. The variance you see is the variance you’ll get in production. Step 5 — Tighten based on failures. What was wrong in any output? Update the instructions to prevent that. Re-test. Loop. Step 6 — Document the skill. Note what it does, when to call it, and what its known failure modes are.
Three patterns that fail
Three patterns that fail.
1. The mega-skill. A skill that “drafts the weekly report including stakeholder updates and exec summary and content calendar.” Break it into three skills. 2. The vague skill. “Help me write.” Define what kind of help, what kind of writing, in what format. 3. The unbounded skill. No context boundaries. The agent reads everything and produces something that sounds related to nothing.
Where this goes wrong
Where this goes wrong.
1. Skipping the five-test step. Skills that work once fail differently. Test variance early. 2. Treating skills as static. Skills need maintenance. When a database schema changes, the skill changes. 3. Building too many skills too fast. Three great skills beat ten mediocre ones.
What to read next
How Notion Skills Work, Custom Agents vs Basic, Workers for Agents, Prompt Patterns That Work Inside Notion.
Engineers hate documentation. Documentation rots. Custom Agents fix the documentation rot without making engineers do the documentation. Standups generate from commits and tickets. Postmortems draft from incident channels. ADRs and runbooks stay current because the agent updates them when related pages change. The engineering org gets the documentation discipline of a regulated industry without the cultural cost.
Four engineering-specific agent patterns
Four engineering-specific agent patterns.
1. The standup synthesis agent. Runs daily at 9 AM. Reads each engineer’s commits since last standup, ticket movements, Slack #standup channel posts. Produces a structured “yesterday/today/blockers” entry for each engineer. The standup meeting becomes a 5-minute review of pre-generated content instead of a 30-minute round-robin. 2. The incident postmortem agent. Triggered when an incident is marked resolved. Reads the incident channel, status page updates, related PRs, and prior incidents. Drafts a blameless postmortem in the team’s template. Engineering reviews and refines instead of starting blank. 3. The ADR maintenance agent. Watches the ADR database. When an architecture page or related design doc changes, flags the related ADR for update. Suggests the diff. Drafts the supersession or amendment record. 4. The on-call runbook agent. Reads operational runbooks, cross-references with recent incidents. When an incident pattern emerges that the runbook doesn’t cover, drafts the runbook update. On-call rotates with current docs, not stale ones.
What stays human
What stays human.
Architecture decisions
Code review (for now — agent-assisted code review is a different topic)
Incident response in the moment
Hiring decisions on engineering candidates
The judgment about whether a draft postmortem captures the right lessons
The standup transformation
Pre-agent standups: 30 minutes, mostly people remembering what they did yesterday and reciting it.
Post-agent standups: 5-10 minutes, reviewing pre-generated content and surfacing only the friction the agent missed.
This isn’t theoretical. Teams running this pattern reclaim 25 minutes per engineer per day. At a 10-engineer team, that’s roughly 4 engineering hours daily. Real money.
Where engineering teams go wrong
Where engineering teams go wrong.
1. Trusting the agent to identify root cause. Agents synthesize what happened. They don’t reliably identify why. Root cause analysis is human work; the agent prepares the timeline. 2. Letting ADRs autofill without engineer review. ADRs document decisions. Decisions are human. Agents draft; engineers approve and sign. 3. Skipping the standup discussion. The standup isn’t just status; it’s friction surfacing. If the agent-generated standup leads to skipping the meeting entirely, friction accumulates silently. Keep the meeting; just make it shorter.
What to read next
Workers for Agents in TypeScript, Notion AI for Product Managers, AI-Native Company Patterns, Editorial Surface Area.
Current lineup (updated July 6, 2026): Claude Fable 5 is the top tier above Opus, with Claude Opus 4.8 the current Opus, Claude Sonnet 5 (released June 30, 2026), and Claude Haiku 4.5. Opus 4.7 is now a legacy model. Full lineup: Claude Fable 5 guide. Claude Opus 4.7 was the flagship when this article was written (April 16, 2026); Opus 4.8 and the Fable 5 top tier have since shipped. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →
What changed if you only have 60 seconds
What changed in 60 seconds.
Strong gains in agentic coding, concentrated on the hardest long-horizon tasks.
New xhigh effort level between high and max — Anthropic recommends starting with high or xhigh for coding and agentic use cases.
Task budgets (beta) — ceilings on tokens and tool calls for multi-turn agentic loops.
Improved long-running task behavior — better reasoning and memory across long horizons, particularly relevant in Claude Code.
/ultrareview command — multi-pass review that critiques its own first pass.
Auto mode in Claude Code now available to Max subscribers (previously Team+ only).
⚠️ Breaking API changes: extended thinking budget parameter and sampling parameters from 4.6 are removed. Update client code before switching model strings.
Tokenizer change: expect up to 1.35× more tokens for the same input.
Context window: unchanged at 1M tokens.
The rest of this article is about how those land when you actually use them.
The coding gain — what it actually feels like
The coding gain — what it feels like.
Anthropic’s release materials describe Opus 4.7 as “a notable improvement on Opus 4.6 in advanced software engineering, with particular gains on the most difficult tasks.” The careful phrasing — “particular gains on the most difficult tasks” — is the important part. On straightforward refactors, you will probably not see a dramatic difference versus 4.6. On long-horizon, multi-file, ambiguous-spec work, you likely will.
In practice, the shift is: 4.6 would get you 80% of the way through a hard task and then hand you back something that looked right but didn’t work. 4.7 is more likely to actually close the task. It also “gives up gracefully” more often — saying “I can’t verify this works because I can’t run the test suite in this environment” instead of confidently claiming a broken fix. GitHub’s own early testing of Opus 4.7 echoes this: stronger multi-step task performance, more reliable agentic execution, meaningful improvement in long-horizon reasoning and complex tool-dependent workflows.
If your 4.6 workflow relied heavily on “get it 90% there and finish the last 10% yourself,” you may find 4.7 changes the calculus. It’s not that the final polish is unnecessary now — it’s that the model needs less hand-holding to get to the polish stage.
xhigh: the new default to reach for
Opus 4.6 had three effort levels: low, medium, high. Opus 4.7 adds xhigh, slotted between high and max.
The reason it exists:max was frequently overkill. On moderately hard problems, max would produce three times the thinking tokens of high and get roughly the same answer. On genuinely hard problems, high would leave thinking on the table. There was a real gap in the middle.
How to use it:
– high is still the right default for routine coding tasks.
– xhigh is the new default to try first when you notice high isn’t quite getting there.
– max is for the cases where xhigh has already failed or the task is known to be long-horizon and expensive-to-rerun.
Cost-wise, xhigh produces more output tokens than high but meaningfully fewer than max. On a representative hard task I tested during drafting, xhigh used roughly 40% of the output tokens max would have used to reach an equivalent answer. Your mileage will vary by task family.
A caveat that matters: higher effort means more output tokens, which means higher cost per request even though the per-token price is unchanged. If your budget alerts are tuned to 4.6 volumes, expect them to fire.
Task budgets (beta): the real agentic improvement
Task budgets — the real agentic improvement.
This is the feature most worth paying attention to if you build agents.
The problem it solves: Agent runs have high cost variance. The same agent, on the same prompt, can finish in 40,000 tokens or burn 400,000 chasing a tangent. Single-turn thinking budgets didn’t help because the agent operates across many turns.
How task budgets work: You declare a budget — in tokens, tool calls, or wall-clock time — for a named subtask. The agent plans against that budget. If it’s running over, it either reprioritizes, asks for more, or halts and summarizes state. Budgets can nest (parent task with child subtasks, each with their own).
What this looks like in code (beta, subject to change):
Behavioral note: Task budgets are soft. The agent is nudged to respect them, not hard-cut. In testing, 4.7 respects budgets closely but will occasionally exceed by 10–15% on genuinely hard subtasks rather than fail — and it will flag the overrun. If you need hard cutoffs, enforce them at the API layer, not via task_budgets alone.
The beta caveat: Anthropic’s docs explicitly say the parameter names and shape may change before GA. Don’t ship this into production contracts that are painful to version.
Long-running task behavior (and Claude Code persistence)
Anthropic’s release note says Opus 4.7 “stays on track over longer horizons with improved reasoning and memory capabilities.” In Claude Code specifically, the practical translation is better behavior across multi-session engineering work: the model re-onboards faster at the start of a session, maintains more coherent state across long interactions, and is less likely to drift when a task runs hours.
This is a capability improvement, not a new memory API. You don’t need to declare anything special to get it — it’s how 4.7 behaves at the model level. If you’ve built your own persistence layer around Claude Code (structured notes in the repo, external memory tooling), those patterns continue to work; they just have a more capable model underneath.
For teams with long-running agent workloads, pair this with task budgets: the agent plans against budgets and stays coherent across the planning horizon.
The /ultrareview command
A new slash command in Claude Code. Unlike /review, which does a single review pass, /ultrareview runs:
A first review pass.
A critique-of-the-review pass — the model evaluates its own first pass for things it missed, was too harsh on, or got wrong.
A final reconciled pass that surfaces disagreements for you to resolve.
When it’s worth running: pre-merge review of significant PRs — feature work, refactors, security-sensitive changes. Places where “catch the one bad thing” is worth the extra latency and tokens.
When it isn’t: routine /review on small PRs. /ultrareview is slow (2–4× the wall-clock time of /review) and not cheap. Anthropic is explicit that it’s not meant for every review.
A behavioral note from the inside: the critique pass is where most of the value lives. A single review pass has a bias toward confirming its own first read. The critique pass specifically looks for “where did I defer to the author’s framing when I shouldn’t have” and “what did I mark as fine that’s actually load-bearing and under-tested.” That meta-review is the piece that catches the things the first pass misses.
Auto mode for Max subscribers
Auto mode — where Claude Code decides on its own when to escalate effort or invoke tools rather than doing what you literally asked — was previously gated to Team and Enterprise plans. As of 4.7’s release, it’s available on Max 5x and Max 20x plans.
For solo developers paying $200/month for Max 20x, this closes a real gap. Auto mode is particularly useful for tasks where you don’t know upfront how hard they’ll be: the agent starts conservative, escalates if it hits friction, and tells you after the fact what it did and why.
The tokenizer change (plan for it)
Opus 4.7 uses a new tokenizer. The same input string can map to up to 1.35× more tokens than under 4.6.
English prose: near the low end (roughly 1.02–1.08×).
Code: higher (roughly 1.10–1.20×).
JSON and structured data: higher still (1.15–1.30×).
Non-Latin scripts: highest (up to 1.35×).
Per-token price is unchanged. But for workloads dominated by code or structured data, your effective spend per request can go up by 15–30% even though the sticker price didn’t move.
The practical step: before you flip production traffic from 4.6 to 4.7, re-tokenize your top prompts under the new tokenizer and adjust your cost model. Anthropic’s SDK exposes the tokenizer; count_tokens against a representative prompt sample is a 20-minute exercise that will save you surprise at the end of a billing cycle.
⚠️ Breaking API changes — do not skip this section
Opus 4.7 is not a drop-in replacement at the API level. Two parameters from Opus 4.6 have been removed:
The extended thinking budget parameter. You can no longer set an explicit thinking budget. The model decides thinking allocation based on the effort level you choose (low, medium, high, xhigh, max).
Sampling parameters. Parameters that controlled sampling behavior on 4.6 are gone on 4.7. Check Anthropic’s release notes for the exact list as you upgrade.
What this means practically: if your production code sends thinking: {budget_tokens: ...} or sampling parameters in its Opus API calls, those calls will fail on 4.7 until you update them. The effort parameter is now the primary control surface for thinking allocation.
The upgrade workflow:
1. Identify every call site that sets the removed parameters.
2. Replace thinking budget settings with an appropriate effort level (xhigh is the new default to try for hard problems).
3. Remove sampling parameter settings entirely.
4. Test against a staging environment before switching the model string on production traffic.
An upgrade checklist
If you’re moving production workloads from 4.6 to 4.7:
Audit your API calls for removed parameters. Extended thinking budgets and sampling params are gone. Fix these first — otherwise calls will fail on 4.7.
Re-benchmark token counts on your top ten prompts. Adjust cost models if needed.
Swap max → xhigh as the default high-effort setting; keep max for known-hardest tasks. Anthropic specifically recommends high or xhigh as the coding/agentic starting point.
Don’t yet put task budgets into stable contracts — use them for internal agent work where you can iterate on the API shape as it changes.
Review output-length alerts. Expect higher output volumes at the same effort level.
For Claude Code users: try /ultrareview on your next non-trivial PR.
For Max subscribers: try auto mode. It’s now available at your tier.
Frequently asked questions
Is Opus 4.7 available in Claude Code?
Yes, as the default Opus model since April 16, 2026. Update to the latest Claude Code version to pick it up.
What’s the difference between high, xhigh, and max? high is the default for routine work. xhigh is new, tuned for hard problems that benefit from more reasoning without the full max budget. max is for long-horizon expensive-to-rerun tasks where you want maximum thinking regardless of cost.
Do task budgets work with streaming?
Yes. Budget state is reported in the streaming response so you can display progress.
Is /ultrareview available on all Claude Code plans?
Yes. Auto mode has a plan gate (Max 5x and above); /ultrareview does not.
Does the tokenizer change affect Opus 4.6?
No. 4.6 continues to use its existing tokenizer. The change applies to 4.7 and any subsequent models that adopt it.
Does filesystem memory work outside Claude Code?
4.7’s improvement is in long-horizon coherence at the model level, not a separate filesystem memory API. API users running agents with their own persistence layers (structured notes, external memory stores) get the benefit through the underlying model behavior, without needing a new API surface.
Did Opus 4.7 really remove sampling parameters?
Yes. If your 4.6 code sets sampling parameters, those calls will fail on 4.7. Update client code before switching the model string.
Related reading
The full release: Claude Opus 4.7 — Everything New
Head-to-head benchmarks: Opus 4.7 vs GPT-5.4 vs Gemini 3.1 Pro
The Mythos tension angle: why the release post mentions an unreleased model
Published April 16, 2026. Article written by Claude Opus 4.7 — yes, the model under discussion.
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
RCP API endpoints at a glance.
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
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
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
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
Existing WordPress REST API queries for RCP.
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
RCP tag ID reference for developers.
Tag ID
Name
Use
409
RCP
All RCP articles — primary filter for the full framework
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
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
Two levels of assurance for contractor Scope 3 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
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
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:
Data entry: Job management system (Encircle, PSA, Dash, manual log)
RCP calculation: Activity data × emission factor = kg CO₂e per domain
RCP Job Carbon Report: JSON record with emissions summary and data quality metadata
Client delivery: Email, ESG platform upload, or API transmission
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:
Pull the portfolio summary for your largest commercial client for the most recent year. Count the total jobs and total tCO₂e reported.
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.
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.
Reproduce one calculation. Take one job record and manually calculate the emissions from the source documents. Verify it matches the reported total within rounding.
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.
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.
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
The business case for RCP 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
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.
Link demolition scope to material weight calculation. Encircle already captures sqft demolished; apply RCP weight-per-sqft table to produce weight by material type.
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
The Xactimate integration opportunity for RCP data.
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:
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:
Capture all 12 RCP data points (primary or proxy with documentation)
Produce valid RCP-JCR-1.0 JSON output that validates against the published schema
Label proxy-estimated data points in the data_quality section
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.
The Restoration Carbon Protocol (RCP) is an open industry self-standard for calculating, documenting, and reporting Scope 3 greenhouse gas emissions from restoration contractor work. It is the first framework purpose-built for the restoration industry to enable contractors to provide defensible, auditor-acceptable emissions data to commercial property managers, REITs, institutional investors, government agencies, and ESG reporting platforms.
This document is the complete RCP v1.0 specification. It supersedes and consolidates all individual RCP knowledge nodes published at tygartmedia.com/esg-restoration. This is the document you share with RIA, with software vendors, with ESG consultants, and with any organization that wants to understand, adopt, or build on the standard.
Version: RCP v1.0 Published: April 2026 Published by: Tygart Media — tygartmedia.com License: Open — free to use, implement, and build upon with attribution GHG Protocol alignment: Corporate Value Chain (Scope 3) Accounting and Reporting Standard Emission factor vintage: EPA 2025 GHG Emission Factors Hub, EPA eGRID 2023, EPA WARM v16
Part I: Purpose and Scope
Part I — purpose and scope.
Why RCP Exists
Commercial property managers, REITs, hospital systems, and institutional facility owners face mandatory Scope 3 greenhouse gas disclosure requirements under California SB 253 (effective 2027 for Scope 3), the EU Corporate Sustainability Reporting Directive (CSRD), and growing pressure from GRESB, CDP, and institutional investors. Restoration contractor work — water damage, fire and smoke, mold remediation, asbestos and hazmat abatement, and biohazard cleanup — generates Scope 3 emissions that appear in the property manager’s inventory as Category 1 (purchased goods and services) and Category 4 (upstream transportation) emissions.
No standard existed for how restoration contractors should calculate, document, or report these emissions. Without a standard, each contractor produced different data in different formats, making it impossible for property managers to aggregate across their vendor base. The Restoration Carbon Protocol fills that gap.
What RCP Covers
RCP v1.0 defines the emissions calculation methodology, data capture requirements, reporting format, proxy estimation procedures, and emission factors for five core restoration job types:
Water damage restoration (IICRC S500)
Fire and smoke restoration (IICRC S700)
Mold remediation (IICRC S520)
Asbestos and hazmat abatement
Biohazard and trauma scene cleanup
RCP v1.0 covers the Scope 3 emissions generated on behalf of commercial clients. Contractor Scope 1 and 2 emissions (the contractor’s own buildings, fleet, and purchased energy) are a separate accounting obligation under the GHG Protocol and are not addressed by the RCP.
Part II: GHG Protocol Alignment
Scope 3 Categories Addressed
Restoration contractor work generates client-facing Scope 3 emissions primarily across four GHG Protocol categories:
GHG Protocol Category
What It Covers in Restoration Work
Included in RCP v1.0
Category 1 — Purchased Goods and Services
Consumable materials, chemicals, PPE, containment, equipment energy (when building-powered)
✅ Yes
Category 4 — Upstream Transportation
All vehicle trips to/from job site, equipment hauls, waste transport
✅ Yes
Category 5 — Waste Generated in Operations
Disposal of demolished materials, contaminated waste, PPE, wastewater
✅ Yes
Category 12 — End-of-Life Treatment
Embedded carbon in building materials removed and disposed of
✅ Yes
Category 7 — Employee Commuting
Technician commuting to contractor’s office
❌ No — contractor’s own Scope 3
Category 2 — Capital Goods
Embedded carbon in equipment (dehumidifiers, vehicles) manufactured
❌ No — contractor’s own Scope 3
Part III: The Five Emissions Calculation Domains
Part III — the five emissions calculation domains.
Every RCP calculation is organized into five domains. Each domain has a primary data source, a calculation method, and a set of proxy values for when primary data is unavailable.
Domain 1: Equipment Energy
Electricity consumed by contractor-deployed drying, filtration, and remediation equipment. Primary method: metered kWh. Proxy method: equipment wattage × runtime hours × proxy unit power draws.
National grid emission factor: 0.3499 kg CO₂e/kWh (EPA eGRID 2023 national average)
Use subregion-specific factor where available (EPA Power Profiler at epa.gov/egrid)
Proxy unit power draws: LGR dehumidifier 1.1 kWh/hr, air mover 0.25 kWh/hr, HEPA air scrubber 0.50 kWh/hr, desiccant dehumidifier 2.8 kWh/hr
Domain 2: Vehicle Transport
All fuel combustion from vehicles operated for job-related purposes. Primary method: fuel volume in gallons. Proxy method: miles × 1/mpg × emission factor.
Diesel (mobile combustion): 10.21 kg CO₂e/gallon (EPA 2025 EF Hub)
Gasoline (mobile combustion): 8.89 kg CO₂e/gallon (EPA 2025 EF Hub)
Proxy fleet mpg: diesel service van 20 mpg; gasoline pickup 18 mpg; diesel dump truck 8 mpg
Debris haul: 0.186 kg CO₂e/ton-mile truck freight (EPA 2025 EF Hub)
Domain 3: Consumable Materials
Embedded carbon in materials consumed during the job but not remaining in the structure: chemicals, PPE, containment materials. Primary method: purchase records by product. Proxy method: standard consumption rates by job type and crew size.
Antimicrobial treatments (default): 2.8 kg CO₂e/liter
Polyethylene containment sheeting: 0.22 kg CO₂e/meter
Disposable Tyvek suit: 1.8 kg CO₂e/unit
N95 respirator: 0.4 kg CO₂e/unit
Nitrile glove pair: 0.12 kg CO₂e/pair
Domain 4: Waste Disposal
Emissions from disposing of materials removed from the property. Primary method: disposal facility manifests by weight and disposal type. Proxy method: weight estimated from demolition scope or volume.
Mixed C&D waste, landfill: 0.021 tCO₂e/short ton (EPA WARM v16)
Drywall/gypsum, landfill: 0.006 tCO₂e/short ton (EPA WARM v16)
Wood debris, landfill: 0.039 tCO₂e/short ton (EPA WARM v16)
Regulated hazmat, incineration: 0.42 tCO₂e/short ton (EPA AP-42)
Biohazardous waste, medical incineration: 0.88 tCO₂e/short ton (DEFRA 2024)
Domain 5: Demolished Materials
Embedded carbon in building materials removed from the structure as a result of restoration work. Primary method: demolition scope by material type and weight. Proxy method: sqft × standard weight/sqft by material type × emission factor.
Standard drywall (½”): 0.12 kg CO₂e/kg (production) — EPA WARM v16
Fiberglass insulation batts: 1.35 kg CO₂e/kg — EPA WARM v16
Carpet (nylon face): 5.40 kg CO₂e/kg — DEFRA 2024
LVP/vinyl flooring: 3.10 kg CO₂e/kg — DEFRA 2024
Dimensional lumber: 0.45 kg CO₂e/kg — EPA WARM v16
Part IV: The RCP 12-Point Data Capture Standard
Every RCP-compliant job record requires twelve data points captured at the time of the job. These are the minimum inputs needed to produce a defensible Scope 3 emissions calculation. Full definitions, good vs. poor capture examples, and calculation mapping for each data point are documented at: tygartmedia.com/12-data-points-restoration-job-scope-3/
#
Data Point
Capture Stage
GHG Category
1
Vehicle log (type, trips, miles, fuel)
Daily / GPS
Cat. 4
2
Waste transport log
Close-out
Cat. 4
3
Equipment power source (building or generator)
Setup
Cat. 1 / Cat. 4
4
Chemical treatments log (volume by type)
During / Close-out
Cat. 1
5
PPE consumption log
During / Close-out
Cat. 1
6
Containment materials log
Setup / Close-out
Cat. 1
7
Debris volume by waste category (weight)
Close-out / Manifest
Cat. 5
8
Disposal method and facility
Close-out
Cat. 5 factor selector
9
Demolished materials by type and weight
Demo scope / Close-out
Cat. 12
10
Replacement materials (if in contractor scope)
Close-out
Cat. 1
11
Job classification (type, category, class, sqft)
Initial assessment
Proxy rate selector
12
Job timeline (start date, completion date)
System-generated
Period assignment
Part V: Proxy Estimation Methodology
When primary data is unavailable — whether for historical jobs, field situations where documentation was incomplete, or data points that current job management systems don’t capture — the RCP authorizes proxy estimation. All proxy calculations must be labeled as estimated in the data quality section of the Job Carbon Report.
The hierarchy of calculation quality, from highest to lowest:
Primary data: Metered, weighed, or directly measured values from job records
Derived primary: Calculated from primary data using standard conversion factors (e.g., miles from GPS × mpg = gallons)
Proxy — job-specific: Estimated using job classification (type, category, class, sqft) with RCP standard rates
Proxy — national average: Used only when job classification is also unavailable. Lowest quality; flag prominently in data quality notes
Part VI: The RCP Job Carbon Report
Part VI — the RCP job carbon report.
The Job Carbon Report is the output document delivered to commercial clients. It is the vehicle by which contractor emissions data enters the client’s Scope 3 inventory. The report has two valid formats: document (PDF or structured text) and machine-readable (JSON per RCP-JCR-1.0 schema).
Wastewater treatment facility emissions from discharged extraction water (flagged for v2.0)
Subcontractor emissions not within the primary contractor’s scope of work
Part VIII: Per-Job-Type Calculation Guides
Each job type has a dedicated technical calculation guide with job-type-specific emission factors, worked examples, and proxy values. These are the source-of-record methodology documents for each restoration category:
U.S. EPA 2025 GHG Emission Factors Hub (January 2025 update)
U.S. EPA eGRID 2023 (published January 2025)
U.S. EPA Waste Reduction Model (WARM) v16
DEFRA UK Greenhouse Gas Conversion Factors 2024
IPCC AR5 Global Warming Potentials (100-year)
Part X: Governance, Versioning, and Contribution
Governance Model
RCP v1.0 operates under a founder-steward governance model. Tygart Media, as the originating organization, maintains editorial control over the standard and is responsible for version releases, emission factor updates, and scope boundary decisions. This model is appropriate for an early-stage standard where consistency and speed of iteration matter more than distributed governance.
As the standard matures and industry adoption grows — particularly if RIA, IICRC, or another industry body formally endorses or houses the standard — governance may transition to a stewardship board model with representation from contractors, property managers, ESG consultants, and software vendors.
Versioning Policy
Version Type
When Issued
What Changes
Backwards Compatible?
Patch (v1.0.x)
Annually or when EPA updates emission factors
Emission factor updates only
Yes — same schema
Minor (v1.x)
When new fields or job types are added
Additive changes — new optional fields, new job type guides
Yes — existing records remain valid
Major (v2.0)
When scope boundaries change significantly
New required fields, scope expansions (e.g., wastewater treatment), LCA-based material factors
Migration path provided
How to Contribute
The RCP is an open standard. Contributions from contractors, software vendors, ESG consultants, property managers, and researchers are actively welcomed. The current contribution process:
Propose: Email rcp@tygartmedia.com with the proposed change, the technical rationale, and any supporting sources. Emission factor changes require a peer-reviewed or regulatory source.
Review: Tygart Media reviews within 30 days and responds with acceptance, modification request, or rejection with explanation.
Publish: Accepted contributions are credited by organization in the version release notes and reflected in the next patch or minor version.
Priority contribution areas for v1.1:
LCA-based emission factors for specific replacement material types
EV fleet proxy values (kWh/mile × grid factor)
Regional proxy rates for markets outside the continental US
Subcontractor emissions inclusion methodology
Wastewater treatment facility emission factors by treatment type
Open Source License
The RCP v1.0 specification, all calculation methodology, the RCP-JCR-1.0 JSON schema, and all associated proxy value tables are released under the Creative Commons Attribution 4.0 International License (CC BY 4.0). You are free to use, share, adapt, and build commercial products on top of this standard with attribution to “Restoration Carbon Protocol v1.0, Tygart Media, tygartmedia.com.”
Part XI: Commercial Application and Regulatory Context
California SB 253
California SB 253 requires companies with California revenues over $1 billion to report Scope 3 emissions for their 2026 fiscal year by 2027. Commercial property managers and REITs in scope must collect contractor Scope 3 data across their vendor base. RCP-compliant Job Carbon Reports provide a standardized format for this data collection. Full context: tygartmedia.com/california-sb-253-2027-restoration-contractors/
GRESB
GRESB Real Estate Assessment submissions (due July annually) require Scope 3 data from property managers’ supply chains, including restoration contractors. RCP Job Carbon Reports in JSON format integrate with major ESG data management platforms (Measurabl, Deepki, Yardi Elevate, Atrius) that aggregate GRESB submissions. Full context: tygartmedia.com/restoration-work-gresb-cdp-disclosures/
CDP Supply Chain
CDP Supply Chain program participants request annual Scope 3 data from their contractors via standardized questionnaire. RCP portfolio-level data aggregation (sum of per-job records by client property) provides the input for CDP Supply Chain responses.
EU CSRD
The EU Corporate Sustainability Reporting Directive requires double-materiality ESG disclosure from large companies, including US-based organizations with EU operations or EU-listed investors. For restoration contractors serving CSRD-obligated property clients, the RCP data format provides the supply chain emissions input required under ESRS E1 (Climate) reporting standards.
Part XII: Software Integration
The RCP is designed to be implemented natively in restoration job management platforms. The 12 data points map directly to field types that existing platforms (PSA/Canam, Dash/Next Gear Solutions, Xcelerate, Encircle, Albiware) already capture or can capture with minimal custom field additions. The RCP-JCR-1.0 JSON schema provides the standard data exchange format for platform-to-platform and platform-to-ESG-tool data transfer.
For a call to restoration software vendors to adopt RCP: see the software integration guide (coming April 2026 at tygartmedia.com/esg-restoration).
Part XIII: Version History
Version
Date
Changes
RCP v1.0
April 2026
Initial publication. Five job types, 12-point data standard, RCP-JCR-1.0 JSON schema, proxy estimation methodology, emission factor reference table, full framework document.
All RCP v1.0 Knowledge Nodes
The following articles constitute the complete RCP v1.0 knowledge base. Each is a standalone reference document that can be read independently or cited as a component of this framework:
