Pole strength remediationChoose onePending
Pole exceeds structural capacity — pick a fix
45 ft pole, 6.5 ft buried, 38.5 ft above ground
Harnesses
A working starting point, not just raw API calls.
Every domain ships a real MCP toolset alongside its REST API — the same compliance and engineering-compute functions, exposed as tools any MCP-compatible agent can call directly. Point an agent at a domain and your team has a working assistant for it, not an empty HTTP client. Five illustrative examples below show what that looks like in practice.
What's included
API access
The same real, cited domain endpoints as any API plan — nothing different underneath.
MCP toolset
Every function in the domain, exposed as a tool over the open MCP protocol — works with Claude, Claude Code, or any MCP-compatible agent you already use.
SDK access
Layer your own utility-specific standards on top with StandardsPack — same mechanism as any API plan.
Self-serve
Point your own agent at it
Pick a domain, get a scoped key, and connect any MCP client you already run — no separate onboarding. Use the SDK to make it yours from there.
Assisted
We build the front end for you
Want a real chat interface deployed and wired to your team's equipment and workflows, not just a toolset? We'll build and deploy that layer on the same API and MCP tools — you still own the customization on top.
Human-in-the-loop, not autopilot
This is what the assisted build looks like in practice. You ask for an analysis of a whole line. The harness runs a structural check and a framing check and proposes fixes: a deeper set, a larger class, a down-guy. Nothing is written back until a person approves it, and a dismissed fix leaves the design untouched. Watch one run, then hover a card to see where its fix lands and approve or dismiss it yourself. It replays on its own until you touch it.
north_feeder.spidaSPIDAcalc project · illustrative
Overhead harness
Loaded north_feeder.spida — 13 poles, 12 spans. Also reads O-Calc and PLS-POLE files.
Run a strength analysis on the entire line.
Overhead harness
Ran the structural check on all 13 poles — 1 pole fails strength, and 3 framing fixes are proposed on Loc 2. Nothing is applied until you approve it.
Framing fixes for Loc 2
3 fixes · 3 pending
Pending
Add down-guy at 346° (CrossArm#1)
Framing on CrossArm#1 at 35.5 ft requires a guy at 346°; no existing guy falls within tolerance. A down-guy sized for the unbalanced load is recommended.
PROPOSED: Add down-guy at 346°, attach at 35.5 ft (crossarm CrossArm#1).
Pending
Add down-guy at 346° (CrossArm#2)
Framing on CrossArm#2 at 30.0 ft requires a guy at 346°; no existing guy falls within tolerance. A down-guy sized for the unbalanced load is recommended.
PROPOSED: Add down-guy at 346°, attach at 30.0 ft (crossarm CrossArm#2).
Pending
Add down-guy at 346° (CrossArm#3)
Framing on CrossArm#3 at 18.0 ft requires a guy at 346°; no existing guy falls within tolerance. A down-guy sized for the unbalanced load is recommended.
PROPOSED: Add down-guy at 346°, attach at 18.0 ft (crossarm CrossArm#3).
Export the approved changes.
Overhead harness
Exported 3 approved changes (1 dismissed, not applied) to north_feeder_revised.spida.
north_feeder_revised.spidaSPIDAcalc project · illustrative
Export as:
Saved ✓ · illustrative, no file is downloaded
PoleExisting
- Height
- 45.0 ft
- Class
- 3
- Set depth
- 6.5 ft
- Structural
- FAIL
- Bending SF
- 1.61 / 2.7
- Capacity
- 168% used
- Framing
- fix needed
Scripted, not live. Every number, id and fix here is made up to show the interaction; the status lines flip by a scripted rule. In a real session the harness only proposes. A person approves or dismisses each fix, and nothing is written back until it is committed. The export formats shown (.spida, .pplx, .pol) are illustrative; which formats are available varies by harness, and no file is produced here.
Approved fixes land in the open design file
When a person approves a fix, the harness makes the change inside the open design file, through the design application’s own automation interface. Each session below shows what that application itself offers for reversing a change, including one case where it offers none.
Most engineering AI today
- Wire#3 at 22.0 ft: raise to 24.5 ft
- Add down-guy at 346 deg
This harness
- Raise Wire#3 22.0 → 24.5 ftApprove
- Add down-guy at 346 degApprove
Wire#3 height24.5 ft
Down-guy346 deg
- Wire#3 22.0 → 24.5 ft
- + down-guy 346 deg
Undo in the application
Check clearances and guying on the open project and fix what fails.
Harness (Claude)
Two problems on the open pole: Wire#3 sits at 22.0 ft, and the pole needs a down-guy at 346 deg.
From the harnessPending
Raise Wire#3 22.0 → 24.5 ft
From the harnessPending
Add down-guy at 346 deg
Harness (Claude)
The window reloads the project with the edit, then autosaves to a session file beside the original. Discard Draft#1 in the application to undo; Measured was never changed. In this desktop path, reviewing the Draft in the application is the gate.
Edits land in a new Draft design; the Measured design is not touched.Writes the fix to a new Draft design in the open project.
The secondary box is at the wrong depth. Fix it.
Harness (Claude)
In the open layout the secondary box is at Z 0.0 ft; it should sit at Z −4.0 ft.
Composed cardPending
Set secondary box Z from 0.0 to −4.0 ft
Composed cardPending
Rotate pad 90 deg
Proposal cards as in the overhead harness; in the raceway, substation and plant sessions the finding is conversational today.
Harness (Claude)
1 step in the application’s own undo.
The application’s own undo reverts bridge placements; observed, not an API.
Undo it in the application: one step of its own undo. The chat has no Undo of its own for this edit.
Add foundation blocks under the disconnect stand, and turn the stand 90 degrees.
Harness (Claude)
Two blocks can be added under the disconnect stand today. Rotating the stand cannot be done through the tools yet.
Composed cardPending
Add two foundation blocks under the disconnect stand
Composed cardPlanned
Rotate stand 90 deg
No update tool today: delete in the application and re-place.
No modify tool today. A correction is delete in the application, then re-place.
Proposal cards as in the overhead harness; in the raceway, substation and plant sessions the finding is conversational today.
Harness (Claude)
The application’s own undo reverted the placed symbols when tried; some underlying records can survive it.
Additive edits only; placed twice, once per block.
The honest-limits beat: the harness can add to the drawing today, not move or rotate what is already there.
Remove the wrong elbow run and connect the unit on the real port.
Harness (Claude)
A wrong elbow run feeds the connector; the connector should land on the real port.
Composed cardPending
Remove the wrong elbow run
Composed cardPending
Re-place the connector on the real port
Proposal cards as in the overhead harness; in the raceway, substation and plant sessions the finding is conversational today.
Harness (Claude)
A delete made through the bridge cannot be undone through it; the application’s undo never recorded it.
Built, unverified: confirmed once on a scratch element, not yet verified for release.plant appplace_row_leg_cdu_connectorlive call
No undo via the bridge: check the removal before you approve it.
Scripted, not live. The windows are drawings, not the applications. Every file name, value and step is made up to show the interaction; the tool calls named are real tools of the harness servers, and a chip marked built or planned says what is not yet verified or does not exist today.
Requires the licensed design application installed, licensed and open on your machine. The harness attaches through the application’s own automation interface and does not replace, bundle or redistribute it.
Design edits run locally on your machine; analysis that proposes a fix sends the design data to the harness API.
Proposal cards as in the overhead harness; in the raceway, substation and plant sessions the finding is conversational today.
Verified so far
Any MCP-capable model can call these tools. The selector includes local models; verified so far: Claude against all applications shown; gemma4 26B and 12B and muse-glimmer 30B via a local server against the compute harnesses only, not yet against the desktop applications. Other hosted models are available in the selector and have not been independently evaluated.
| Model | What was tested | Result | Caveats |
|---|---|---|---|
| Claude | Live against the desktop applications shown (pole-analysis, raceway, substation and plant sessions). | Not formally scored. | Live use only; no scored evaluation of the desktop tools. |
| gemma4 26B (local server) | Tool-calling eval against the compute harnesses’ tool schemas. | 100% on transmission, underground, substation, DER and building-service; 60–70% on overhead. | Compute harnesses only, not the desktop applications. Slow over the full 103-tool overhead set on a local machine; results vary run to run even at temperature 0. |
| gemma4 12B (local server) | Same eval, same tool schemas. | 100% on transmission, building-service, substation and DER; 67% on underground; 40% on overhead. | Compute harnesses only. A four-turn overhead chain needed a longer request timeout than the default. |
| muse-glimmer 30B (local server) | Same eval, same tool schemas. | Raw: 100% transmission, 78% underground, 60% overhead; 11% substation, 0% DER, 75% building-service. Projected 100% on those last three after a dispatch normalisation fix, which is deployed. | Compute harnesses only. The 100% is projected from the model’s captured outputs, not a re-run score. |
| Other hosted models | Nothing. | Available in the model selector. | Not independently evaluated. |
See it for real
A short screen recording of the harness editing a scratch design file goes here.
Stage by stage: generation to substation
A generation plant and then its substation, walked through their design stages. The design basis is entered once; each stage says valid, incomplete, failed, stale or missing, and nothing passes by default. The plant’s fault contribution reaches the substation as a versioned hand-off, and a breaker that was adequate on the grid alone turns out not to be with the plant. A short coda runs the same pattern on a transmission line. It replays on its own until you touch it.
riverbend_plant.basis.jsondesign basis · illustrative
Assistant
Design basis loaded. Nothing has been run.
Start the plant design and size the step-up transformer.
Generation design
Plant design started and the generator stage run. The nameplate, 31.25 MVA at 0.8 power factor, gives 25 MW and 18.75 Mvar, and 8.716 kA subtransient at the generator terminals. The manual’s multiplier is outside its tabulated range for this unit, so it is reported, not judged.
The route exists in the REST API. The result shown is scripted, not a live response. Draft, unvalidated harness.The route exists in the REST API. The result shown is scripted, not a live response. Draft, unvalidated harness.
Generation design
Step-up transformer: 35 MVA against 29.25 MVA net output, a ratio of 1.12, so it does not limit the plant. On the 34.5 kV side the generator contributes 141.129 MVA, 2.3618 kA. That figure is generator-only: the grid is not in it.
ugmgeneration_design_run_stagelive route
Generation design
Station service: the 2.5 MVA auxiliary transformer is 8% of the generator MVA and covers the 2.2 MVA required. The stage stays incomplete: motor starting, load classification and a standby transformer are not evaluated.
ugmgeneration_design_run_stagelive route
Generation design
Grid interface: the governor droop and deadband pass FERC Order 842 (5% droop, 0.036 Hz) and the generation_to_substation hand-off is built. The stage stays incomplete: reactive capability at the point of interconnection, plant X/R and stability are not evaluated.
The route exists in the REST API. The hand-off is a versioned JSON object (contract version 1, generation_to_substation) that a person passes into the substation design; it is not a pipeline, and it carries no hash of the generation state it came from. The result shown is scripted. Draft, unvalidated harness.
Hand-off · contract v1Pending
Send the generation_to_substation v1 hand-off to the substation design
141.129 MVA, 2.3618 kA at 34.5 kV, generator-only: the substation adds its grid source to it.
Contract v1 has no field for the state of the stage the hand-off came from, so the receiver has to check that itself. It is a JSON object passed between the two designs, not a pipeline.
Draft, unvalidated harness · illustrative values.
Start the 34.5/12.47 kV station design with that hand-off.
Substation design
Station design started. The stages run on the grid source alone first (1000 MVA), so what the plant changes can be seen on its own. A ring bus with 4 circuits implies 4 breakers. The HV fault level at 34.5 kV is 16.735 kA.
usmsubstation_design_startlive routeThe route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.The route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.
Substation design
Then the transformer, the LV fault study (12.191 kA at 12.47 kV) and the equipment ratings. The illustrative 17.23 kA HV breaker covers the grid-only duty: adequate on the duties evaluated, margin +0.495 kA. The stage stays incomplete, never valid: asymmetry is not evaluated.
The route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.The route exists in the REST API. The breaker rating is an illustrative input (grid-only duty plus 0.5 kA), not a product. This stage can only return failed or incomplete: asymmetry is never evaluated. The result shown is scripted. Draft, unvalidated harness.
Substation design
Now the plant. The hand-off goes into the design basis, and every stage computed from the old basis is stale (upstream object of stage ’design_basis’ changed). Re-run in order, the plant’s 141.129 MVA is added to the grid’s 1000 MVA: 1141.129 MVA, and the HV fault level rises to 19.097 kA (+2.362 kA). The same 17.23 kA breaker is now inadequate: capability 17.23 kA against 19.0966 kA required, margin -1.867 kA. Equipment ratings is failed.
The route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.The route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.
Substation design
The harness proposes one fix, verified by re-running the stages on the patched basis.
The route exists in the REST API and returns verified proposals only (each candidate is re-run through the stages before it is offered). The proposal card shown is scripted, not a live response. Draft, unvalidated harness.
Verified proposalselectPending
Verified fix: set the HV breaker interrupting rating to at least 19.5 kA
Minimum found: HV ≥ 19.10 kA. Select a catalog breaker at or above 19.10 kA: a minimum is not a product.
Needs selection: a catalog breaker rated at or above the minimum (the RUS preferred-rating tables are not yet transcribed in this harness).
Verification and consequences
Verification (re-ran design_basis, upstream stages and equipment_ratings on the patched basis)
before failed: HV: capability 17.23 kA < available three-phase fault 19.0966 kA; NOT EVALUATED duty dimension: asymmetry (S-factor / X/R); …
after incomplete; no new findings
Consequences
- The kA given is the MINIMUM rating that clears the evaluated duties (three-phase symmetrical and SLG), not a product: pick the catalog breaker at or above it and enter its rated max kV, K and your highest operating kV so the Eq. 5-3 credit is computed rather than skipped.
- Asymmetry / X-R duty (IEEE C37.010) is still NOT evaluated: this stage stays incomplete even after the fix.
- A higher-rated breaker may change the bus short-circuit bracing and the protection coordination assumptions.
Draft, unvalidated harness · breaker rating illustrative.
Substation design
Applied. The design basis is patched (hv_breaker_interrupting_ka 17.23 to 19.5) and nothing else is re-run for you: electrical_topology, fault_study, transformer, lv_fault_study and equipment_ratings are all stale. Next recommended: electrical_topology, fault_study, transformer. Running them in order.
The route exists in the REST API. Applying patches the design basis and re-runs that stage only; every dependent stage is then stale and nothing else is re-run for you. A dismissal needs a reason. Scripted result.
Substation design
Equipment ratings re-run: the HV breaker at 19.5 kA against 19.097 kA required, adequate on the duties evaluated, margin +0.403 kA. The stage is still incomplete, never valid: asymmetry and X/R duty, single-line-to-ground duty and the voltage factor are not evaluated. 19.5 kA is a minimum, not a product.
The route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.
Same tools, a line: DRAKE at 138 kV, 150 MVA.
Line design
The same stages for a line. Conductor ampacity: 627.55 A required against 972 A rated (64.56%): valid. Sag and tension at an 800 ft ruling span: initial sag 17.504 ft. The heavy case is 10,989.8 lb, 34.89% of rated breaking strength, within the 60% limit; the bare case is 15.87%, within 35%; the hot case sags 25.43 ft and is reported only. The stage stays incomplete: post-creep tension is not evaluated.
The route exists in the REST API. The sag-tension stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.The route exists in the REST API. This stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.
Line design
Edit the ruling span from 800 to 900 ft: conductor ampacity and sag_tension are stale (upstream object of stage ’design_basis’ changed). Next recommended: conductor_ampacity, sag_tension, structure_span. Re-run at 900 ft: initial sag 22.154 ft, heavy case 35.1% of rated breaking strength. There is no hand-off from this line to the station yet.
The route exists in the REST API. The sag-tension stage calls a sibling harness over HTTP and returns incomplete when it is unreachable; whether the live gateway can reach that sibling is NOT verified. The numbers shown were produced offline with the sibling run in-process, and this card is scripted, not a live response.There is no hand-off from the line design to the station design today. The dashed arrow shows where one would go; nothing in the harness builds or accepts it yet.
Summarize the station design.
Substation design
Station design summary. This is the state the stages built up, not a verdict.
The route exists in the REST API. The result shown is scripted, not a live response. Draft, unvalidated harness.
Design summaryall_stages_valid: false
- all_stages_valid
- false
- open_items
- bus_clearances [missing]: not run · equipment_ratings [incomplete]: NOT EVALUATED duty dimension: asymmetry (S-factor / X/R); …
- standards_cited
- 3 · RUS Bulletin 1724E-300 §4.6 · RUS Bulletin 1724E-300 section 5.3.3.2.4.3 Eq. 5-3 and section 5.3.3.2.4.5 · IEEE Std 551-2006 Ch. 4 (via circuit-calc-harness)
- sibling_calls
- circuit-calc-harness:calculate_available_fault_current
disclosure DRAFT / UNVALIDATED. Derived design values, not a licensed-engineer sign-off. INCOMPLETE stages were not fully evaluated; do not read them as passed.
Draft, unvalidated harness.
Substation design
Design summary exported.
station_design_summary.json.json design summary · illustrative
Export as:
Saved ✓ · illustrative, no file is downloaded
Scripted, not live. Every number here comes from running the harness design workflow offline (generation, substation and transmission, run in-process at export time). The routes behind the chips are live in the REST API, but this demo does not call them, and the cards are scripted. The fault-study and sag-tension stages call sibling harnesses; whether the deployed gateway can reach them is not verified, so no working REST chain is claimed. The breaker ratings are illustrative: 19.5 kA is a minimum the harness found, not a product. The hand-off is a JSON object a person passes between two designs, and contract version 1 has no field for the state of the stage it came from. The status card never shows an overall verdict, and the export (.json) is illustrative: no file is produced. The loop runs about 100 seconds.
Harness maturity: generation, substation and transmission design workflows are draft, unvalidated harnesses; stages marked incomplete were not fully evaluated and should not be read as passed.
One design, six harnesses
A grid-fed datacenter hall, reviewed from the tap line to the cooling loop. Each harness checks its own stage and hands a result to the next. Two problems only show up when the stages are read together: the available fault current against the service device, and a hall that is redundant behind a station that feeds it on one circuit. Watch one run, then hover a card to see where its fix lands and approve or dismiss it yourself. It replays on its own until you touch it.
green_valley_dc.design.jsoncross-domain design bundle · illustrative
Gateway
Loaded green_valley_dc.design.json: a grid-fed datacenter hall, six stages from the tap line to the cooling loop. Nothing has been checked yet.
Review the whole design, grid to rack.
Gateway
Six harnesses will review this design, one stage at a time: tap line, station, duct bank, hall, service gear and cooling. Each stage hands its result to the next. Nothing is applied until you approve it.
Illustrative composition. Each harness named in this review is a real, separate toolset; one prompt that sequences all six is what this mockup shows, not a shipped call.
Transmission harness
Tap line first. A class 1 pole at a 500 ft span exceeds its capacity at heavy loading.
Draft, unvalidated harness. The scene is a composite of bulletin worked examples, not one real structure.The route exists in the REST API. The span fix card shown here is scripted, not a live response. Draft, unvalidated harness; a failed span means it fails against the stated factors, not necessarily the code.
Tap line · span classChoose onePending
Class 1 pole exceeds its capacity at a 500 ft span
55 ft pole, heavy loading. Maximum span for class 1: 423.0 ft.
Draft, unvalidated harness · composite of bulletin worked examples (illustrative geometry).
Substation harness
Station next. Breaker-and-a-half with 4 circuits has 6 breakers (pass). The fence is the finding.
usmcheck_bus_configuration_breaker_countlive callDraft, unvalidated harness. Illustrative station geometry.The route exists in the REST API (a verified fix for a single failing check, with no design state). The fence fix card shown here is scripted, not a live response. Draft, unvalidated harness.
Station · fence clearancePending
Fence is 15.0 ft from live parts; 15.4 ft required
Raising the insulation level to BIL 900 kV asks for more fence clearance than the existing fence gives.
PROPOSED: Move the fence out to 16.0 ft (15.4 ft required).
Draft, unvalidated harness · illustrative station.
Underground harness
Underground. Four feeders in one row derate the whole bank.
Draft, unvalidated harness. Grouping factors are secondary-sourced. Treating separate banks as thermally independent is a demo assumption: the harness has no inter-bank model.
Underground · duct bankChoose onePending
Four feeders in one row: bank ampacity 205.5 A, feeders 1 and 2 are over it
Four 350 AL feeders. Alone, one conduit carries 263.5 A; the row derates all four.
Draft, unvalidated harness · grouping factors secondary-sourced · separate banks treated as thermally independent (a demo assumption).
Datacenter harness
Hall. The cooling pumps pass N-1 only partly.
v0.1 draft, unvalidated harness. The N-1 pumps verdict comes from the harness; the lose-one-pump consequence shown is worked out by the demo.
Hall · cooling pumpsPending
Pumps 2+0: N-1 is tight, duty short after losing one
Two duty pumps and no standby: when one trips, the duty count is not met.
PROPOSED: Add a standby pump (2+1). N-1 duty is then kept.
v0.1 draft, unvalidated harness.
Service harness
Service gear, checked on its own at the 5 MVA source entered earlier: the 22 kA device is within the 13.9 kA available.
Draft, unvalidated harness. X/R is not gated: pass means adequate under a symmetrical screening comparison.
Gateway
That changes once the station result is handed over. The station study puts a 10 MVA source behind the service.
By contract between harnesses, not a shipped pipeline. The substation fault-study stage exists in the REST API (substation_design_run_stage), but it calls the circuit harness and returns incomplete if that harness is unreachable; whether the live gateway can reach it is not verified here.circuitcalculate_available_fault_currentlive call
Service · interrupting ratingAcross stagesPending
22 kA device against 27.8 kA available: exceeds
Handed from the station study: a 10 MVA source (illustrative) gives 27.8 kA at the service. A 25 kA device also exceeds it.
PROPOSED: Swap to a 42 kA device (within).
Draft, unvalidated harness · X/R not gated.
Gateway
One more finding, only visible across the fence between hall and station.
Draft, unvalidated harness. The hall-to-station redundancy comparison is composed by the demo, not by a harness.
Hall and station · feed redundancydemo-logic compositionPending
The hall is N+1, but the station feeds it on one circuit
The hall passes N-1 on its own. If the outer breaker on that circuit fails to clear, the circuit is lost (the station study leaves 3 of 4 circuits), and the hall loses its only feed. Adding a fifth circuit cannot be checked: the breaker count is incomplete, with no exact target for 5 circuits. Six circuits need 9 breakers.
PROPOSED: Add a second feed circuit to the hall (a capital decision).
Draft, unvalidated harness.
Thermal harness
Cooling. Lose CDU-2 and the survivors still carry the heat, but their legs run too fast.
v0.1 draft, unreviewed harness. Velocity limits are ASHRAE guidance reached through secondary sources.thermalpropose_pipe_diameter_remediationlive call
Cooling · CDU lossPending
After losing CDU-2, survivor legs run 2.837 m/s, above the 2.100 m/s cited limit
Capacity holds with two units (2000 kW against 1920 kW demand), but each survivor’s 4 in leg now carries half the row flow.
PROPOSED: Use 6 in legs: 1.261 m/s, within the limit.
v0.1 draft, unreviewed harness · ASHRAE limits via secondary sources · illustrative placeholders.
Export the cross-domain review.
Gateway
Exported the review.
green_valley_dc_cross_domain_review.pdfReview report · illustrative
Export as:
Saved ✓ · illustrative, no file is downloaded
Scripted, not live. Every id, name and sequence here is made up to show the interaction; the numbers are values from the harnesses’ own worked examples and are illustrative. In a real session each harness only proposes: a person approves or dismisses every fix, and the dismissed station-feed risk stays open. The status card never shows an overall verdict, and the export formats (.pdf, .json, .csv) are illustrative: no file is produced. The loop runs about 90 seconds. The station-to-service source-strength hand-off is by contract between harnesses, not a shipped pipeline.
Harness maturity: tap line, station, duct bank and service gear: draft, unvalidated harness (the tap line scene is a composite of bulletin worked examples; duct-bank grouping factors are secondary-sourced, and treating separate banks as thermally independent is a demo assumption; the service check does not gate on X/R). Hall: v0.1 draft, unvalidated harness. Cooling: v0.1 draft, unreviewed harness (velocity limits are ASHRAE guidance via secondary sources).
One toolset, either path
This isn't a separate product from the API — it's the same domain, the same key, the same SDK. The only choice is how much of the front end you want to build yourself versus have us build for you.