This is the private software runtime — coded constitutional rules, not a PDF dump.

Operating context for the architecture: ~13–15 branches, 750+ employees, Midwest region, multi-trade field service. This is a design target, not a production deployment or customer count.

Primary integration posture: BYO — each user incorporates their own ServiceTitan and ProBooks into their local runtime. A trades-app drop-in covers other field-service exports in the same class, preferring a named profile (Jobber, Housecall Pro, Service Fusion, QuickBooks, ServiceM8, AccuLynx, SuccessWare, Xero, FieldEdge, ServiceTrade) when the fingerprint matches. Peer inbound. Read-only. The human operator desk is npx tsx src/cli.ts desk on that machine, including local alert rules from data/runtime/alerts.json.example and the local AZTrades shell (clock, meal, drive, job price, local login, property card, SupplyHouse public GET). That shell is Local Softwares only. live_backends false. pilot_started false. Not Field 1.0. SupplyHouse is a public GET when a number returns; the typed cost remains when unavailable (403 or no number); no order path. Other named suppliers stay empty until a permitted account. The property card is company history only. Zillow, Redfin, and a county assessor are not connected until a permitted source. Local login: the first user is okayed; later users need higher approval. No ServiceTitan or Jobber write-back from this shell. Authoring node / GitHub is not a data custodian. No central dump. No hosted uploader. No phone-home. Credentials stay on the user’s machine.

• Not a simple dispatch optimizer.
• Not a leaderboard that equates revenue with technician quality.
• Not a fixed morning route planner.
• Not an autonomous black box that can silently overrule humans.
• Not an AI that treats a photo inference as proof of fault or misconduct.
• Not a fuel-minimization system that sacrifices technical fit or customer outcome.
• Not a system that assumes a 30-day return visit is automatically a technician callback.