Example pack: Abingdon Taxi Solutions

What AI TrustBOM produces for a fictional AI-first taxi company, from a first scan to answers for a buyer's questionnaire.

Synthetic example. Abingdon Taxi Solutions, its service, its Gemini and MCP setup and its customer's RFI are fictional and come from a public starter repository. The output shown is selected and representative; fingerprints are placeholders and real values vary between checkouts. Nothing here is a customer or a real deployment.

Abingdon Taxi Solutions is the vendor. Its customer, who sends the questionnaire, is the buyer. Trust is the person at Abingdon allowed to approve what is shared. You can reproduce every step from the public starter repository.

1. A scan produces a cited draft

After the platform team records a proposed Gemini integration, trustbom scan adds the model to the graph. Each row cites the exact files that justify it. This is an excerpt of trust/card.json:

{
  "models": [
    {
      "provider": "gemini",
      "model_id": "gemini-2.5-flash",
      "source": "inferred",
      "evidence": [
        { "path": "config/models.yaml", "start_line": 1 },
        { "path": "requirements.txt", "start_line": 1 }
      ]
    }
  ],
  "findings": [
    { "id": "region-unknown", "severity": "medium" },
    { "id": "subprocessor-undeclared", "severity": "medium" }
  ]
}

The two findings give Trust concrete questions: where does inference run, and which processor agreement covers it? The card is labelled as a draft:

# AI TrustBOM system card
> **draft (unapproved)**
...
- **System:** Abingdon Taxi Solutions service

2. The questionnaire is rendered from the same graph

Answers come from the graph, with citations. Anything the evidence does not support stays unknown rather than being guessed:

status: "draft (unapproved)"
questions:
  - id: Q2_models_and_vendors
    question: "Which models and vendors are used?"
    answer: "gemini: gemini-2.5-flash"
    cite:
      - "config/models.yaml"
      - "requirements.txt"
  - id: Q3_is_customer_data_used_to_train
    question: "Is customer data used to train?"
    answer: "unknown"
    cite: []

3. The gate stops unreviewed change

Adding a tracked MCP connection for driver earnings creates a new row in the graph. With no approved baseline yet, trustbom gate reports that a bootstrap approval is required and lists the unresolved findings, exiting with code 3 so a pull request check can fail:

**Status:** bootstrap required
**Draft classification:** role `unknown`, high risk `unknown`, Article 50 `unknown`
### Findings
- `medium` **region-unknown**: The deployment region for gemini could not be determined.
- `medium` **subprocessor-undeclared**: Provider 'gemini' has no declared subprocessor.

4. Trust approves, then the buyer's RFI is answered

In a real vendor repository, Trust checks the evidence, records the approval in trust/approvals.yml, a different CODEOWNER reviews and merges it, and the default branch is stamped. Only then can the approved pack be exported and the buyer's questionnaire answered. On the starter repository no approval is stamped, so trustbom answer refuses rather than answering from a draft.

For an approved graph, a buyer's CSV question comes back with an answer, its citations and a confidence. For example, a question the evidence cannot support:

"id","question","section","answer","cites","confidence"
"RFI-03","Is customer data used to train?","Data governance","unknown","trust/card.json","low"

A question outside the fixed question set goes to a person instead of being invented:

"id","text","section"
"RFI-06","How do drivers managers and owners use AI in your service?","Customer experience"

That second file is the unmatched list: Trust follows up and answers it by hand. unknown and unmatched rows are the product being honest about what the evidence does not show.

Install and try it See pricing