← All work

Spine

Software where it helps. A person where it counts.

A decision framework for what software does, what a person approves, and what stays human, offered first to owner-led trade businesses.

The idea

Owners of small plumbing, HVAC, and electrical businesses keep hearing that they should add AI, but nobody helps them decide where it belongs. Automation lands on the wrong steps, a routine message goes out when a customer needed a person, and every job still ends up waiting on the owner. Spine is for the owner-led trade business that wants less chasing without handing its judgement to a tool.

The service begins by watching, with permission, how a real job moves from first enquiry to payment. Each step then gets a written decision: software runs it under agreed rules, software prepares it and a person approves, or a person does it because a person doing it is the point. Agreed changes are built and tested with clear stop and override steps. Underneath is one conviction: accountability cannot be handed to software, so the human role is designed first.

The small end comes first because a trade business writing down how a quote gets made is doing the same work, at lower fidelity, that larger organizations will need later, so the method is meant to grow with them. Today Spine has that written method, a live public offer, and a private research console. No client engagement has run yet, and pricing is not set.

How it works

  1. Observe the work
  2. Map the job
  3. Decide each step's boundary
  4. Build and test

The method classifies each step of a job four ways: software does it, software drafts and a person decides, software acts and a named person answers for it, or a person does it because that is the point. Safety gates run before any scoring, so a strong score on one axis cannot buy down a dangerous one. The private console keeps public review evidence, AI interpretation, and decisions in separate, append-only records.

Where it stands today

Spine has a written method, a live public offer for owner-led plumbing, HVAC, and electrical businesses, and a private working console. The console keeps evidence, interpretation, and decisions separate: public customer-review evidence, a registry that records how each step of work is classified and who is answerable, and a partial outside-in diagnostic. No client engagement has run, and pricing is not set. The diagnostic calculates, but has not yet shown it can tell similar businesses apart.

Working now

  • A live public site for trade-business owners, with a guided, fictional plumbing-job example and a conversation-first offer
  • A four-way classification of work, with safety gates applied before scoring
  • A boundary registry with append-only, versioned decisions and a review of every changed input
  • An evidence view of public customer reviews that keeps raw evidence apart from AI interpretation
  • Release gates: unit, database-security, build, and browser checks, with 66 public checks passed against production

Not there yet

  • No client engagement has run, and the diagnostic does not yet separate similar businesses.
  • The composition and automation layer is unbuilt.

How it got here

  1. Started from a business-intelligence dashboard template with a store of public customer-review signals
  2. Re-founded as Spine: a written method for where AI belongs in a business, with public principles and a private working doctrine
  3. Audit console and boundary registry first implemented; claims that cite evidence which does not exist are rejected
  4. Finding kept on record: the outside-in diagnostic does not tell similar businesses apart. The trades offer was written down
  5. Truth-gated signed-in surfaces rebuilt and locally accepted, with public signup disabled
  6. Public face rebuilt trades-first, for plumbing, HVAC, and electrical owners, with a fictional example job

What comes next

Next step

A first conversation with a trade-business owner that confirms the offer is understood, leading to an agreed, scoped first engagement.

Later ideas, not current features

  1. Have an unfamiliar trade-business owner review the public page cold
  2. Hold first conversations with trade-business owners and decide the terms of a first engagement
  3. Run an attended review of the console with an owner-controlled production account
  4. Decide whether the outside-in diagnostic is revised, narrowed, or kept as explicitly non-discriminating
  5. Calibrate owner time and sequencing from real attended work before building more

What I checked, and what stays bounded

Dated evidence

  1. Audit console and boundary registry first implementedrepository
  2. Truth-gated signed-in surfaces rebuilt and locally accepted: 24 migrations replayed from empty, 12 of 12 security checks passedrelease
  3. Trades-first public site released; 66 public checks passed against productionrelease

Boundaries it keeps

  • No client engagement, pilot, or paying customer yet, and no client results or testimonials
  • Pricing is not set
  • The website example is fictional: it sends nothing and connects to no customer system
  • The outside-in diagnostic is not a readiness score and has not shown useful discrimination between similar businesses
  • The signed-in console is implemented and locally tested; production operator use is not yet verified
  • No composition or automation layer is built, and no autonomous action is claimed
  • The businesses in the review data are third parties studied from public reviews, not clients
  • Private doctrine remains private

My role

Wrote the thesis and method, chose the trades-first direction, and directed, reviewed, and accepted each release.