← RigReceipts Freight EconomicsCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to RigReceipts Freight Economics
Snapshot Sep 30, 2026 · 23:11 UTC · version 1.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "freight-economics",
"description": "Evaluate whether a specific freight load offer makes economic sense for an owner-operator or carrier using the carrier's own weekly operating costs, loaded miles, deadhead, break-even, and target economics.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 291
},
{
"relative_path": "references/methodology.md",
"size_in_bytes": 998
}
],
"skill_md_contents": "---\nname: freight-economics\ndescription: Evaluate whether a specific freight load offer makes economic sense for an owner-operator or carrier using the carrier's own weekly operating costs, loaded miles, deadhead, break-even, and target economics.\n---\n\nUse this skill when a user asks whether a specific freight offer is economically attractive, whether they should accept/counter/pass based on operating economics, or what gross rate would be needed to meet their target.\n\n## Required workflow\n\n1. Gather the values required by `evaluate_load_offer`:\n - offered pay\n - loaded miles\n - deadhead miles\n - weekly fixed operating costs\n - variable operating cost per mile\n - projected total weekly miles\n - expected loaded weekly miles\n - desired weekly driver pay\n - desired weekly reserve/profit\n\n2. Never invent carrier-specific costs. If required values are missing, ask only for the missing values. If the user explicitly requests an example or rough scenario, clearly label assumptions before calling the tool.\n\n3. Call `evaluate_load_offer` when the required inputs are available.\n\n4. Treat the tool response as the canonical economic calculation. Do not recompute the verdict using a different RPM definition.\n\n5. Explain results in this order:\n - ACCEPT / COUNTER / PASS\n - offered loaded RPM\n - offered all-mile RPM\n - all-mile break-even RPM\n - all-mile target RPM\n - target gross for the evaluated miles when useful\n - margin/contribution over break-even\n - deadhead share\n - short reason for the verdict\n\n## Canonical semantic distinction\n\n- `target_loaded_rpm` is a weekly revenue-mile planning metric.\n- It does NOT control the verdict for a specific offered load.\n- A specific offered load is evaluated using offered all-mile RPM against all-mile break-even RPM and target all-mile RPM.\n\n## Hard boundaries\n\nRigReceipts V0 is economic decision support only.\n\nDo not claim or imply that it:\n- searches load boards or finds freight;\n- contacts brokers, shippers, carriers, or facilities;\n- negotiates, bids, books, accepts, rejects, tenders, or dispatches freight;\n- verifies hours-of-service, route legality, equipment suitability, insurance, safety, regulatory compliance, contract terms, or counterparty/payment reliability;\n- guarantees profit or actual trip outcome;\n- reads private RigReceipts account records in anonymous V0;\n- persists the user's offer or operating-cost inputs.\n\nFor unsupported operational/transactional requests, state the boundary briefly and offer to evaluate the economics of a user-supplied load when useful.\n\n## Output discipline\n\nUse the dollar/RPM values returned by the tool. State that the result depends on user-supplied operating assumptions. Do not describe margin over break-even as guaranteed net profit.\n\nIf the tool returns input validation failure, request correction of the invalid input instead of fabricating an answer.\n"
}SHA-256: a402449114e47cc3087d91e03b69a0a1fb7fa238f934c32413d06f1f0d497cdc