proverify.ai
Talk to us
17 Jul 2026 · Field Note · TokenOps · Internal Dog Fooding

Dog Fooding at Proverify

We have been using two simple internal views—one over ChatGPT history, one over GitHub activity—to learn what TokenOps can actually measure before we ask customers for deeper integrations.

TokenOps Dog Fooding ChatGPT GitHub

What we are actually doing

  • Start with exports we already have. We built one internal analysis over ChatGPT conversation history and another over GitHub activity. Neither requires us to claim an integrated enterprise control plane.
  • Turn activity into a reviewable population. The useful outputs so far are straightforward: usage and estimated-cost views for ChatGPT; activity, R&D classification, AI-signal and evidence-review views for GitHub.
  • Keep the claims narrower than the ambition. We are not yet claiming that a ChatGPT conversation caused a GitHub artifact, that line changes equal productivity, or that a GitHub classifier by itself produces an accounting conclusion.

There is a temptation in enterprise AI to jump from raw usage telemetry directly to ROI, accounting treatment or control conclusions. Our internal dog-food work has been more basic.

We asked: What can we learn from data we already control, with a small amount of normalization and classification?

So far, that has produced two practical internal tools.

1. A ChatGPT usage audit

Our first view is a searchable audit of internal ChatGPT history. It does not try to prove business outcomes. It organizes conversation activity into a more useful management view.

Internal output 1
ChatGPT Usage Audit
The fields below are the analyses present in the internal dashboard we have actually used.

Usage & estimated economics

Conversation-level usage summarized into simple operating views.

tokens by month estimated cost by month top costly conversations
+

Classification & review

Conversation records can be searched, filtered and classified into working management categories.

category by tokens value tiers function distribution conversation registry AI census
What this supports today Where conversation capacity is being spent.

It gives us a concrete way to inspect usage, estimated cost and working classifications. “Estimated cost” and “value tier” are analytic fields—not audited finance measures or proven business value.

Internal ChatGPT usage audit dashboard showing conversation-level tokens, estimated cost and classification views. Screenshot: internal ChatGPT usage audit

2. A GitHub R&D activity and capitalization view

The second tool starts from GitHub commits and pull requests. It classifies work by R&D phase and activity type, flags an AI signal where one is detectable, and assigns each work item a working yes / review / no capitalization status with rationale and evidence needed.

One actual internal reporting window: 15 May–15 Jul 2026
  • 593 work items across 41 repositories.
  • 81 pull requests and 512 commits.
  • 1.81M recorded line changes. This is an activity measure, not a proxy for labor, productivity or value.
  • Working R&D classification output: 144 yes, 145 review, 304 no — a 24.3% “yes” rate.
  • AI signal: 80 explicit, 2 inferred, 511 not detected. A signal indicates available evidence, not the percentage of work performed by AI.
Internal output 2
What the R&D dashboard actually surfaces
The useful part is the work-item register and review logic, not the headline KPI alone.
Activity
Commit / pull request / repository / component / language / changes Direct GitHub-derived activity fields form the underlying population.
source record
Classification
R&D phase + activity type + yes / review / no candidate The dashboard separates research, development, operations and post-implementation activity, with a written rationale.
working judgment
Evidence
Rationale + evidence needed + AI signal Review items can identify what additional evidence would be needed rather than forcing a definitive answer from the Git record alone.
review queue
Internal GitHub R&D activity dashboard showing work items, classification and review queue. Screenshot: internal GitHub R&D activity and capitalization view

3. What dog fooding is teaching us

The main lesson so far is not that we have solved enterprise AI attribution. It is that relatively simple exports already support a more structured operating file than a collection of screenshots and anecdotes.

What we can defend today
Four grounded observations
1
Native exports are a credible place to start. We can create useful populations from ChatGPT history and GitHub activity before building production-grade integrations.
2
Classification is useful even when it is imperfect. A yes / review / no structure is more useful than hiding uncertainty, provided the rationale and review population remain visible.
3
Evidence gaps are themselves an output. The GitHub view can identify missing project approval, phase, intent, feasibility or cost support rather than pretending the repository contains everything accounting needs.
4
Usage metrics need careful interpretation. Tokens, estimated cost, line changes and AI signals are observable indicators. None should be presented as business value without additional evidence.

4. What we are not claiming yet

Keeping these boundaries explicit is part of the dog-food exercise.

Current boundaries
The next layer is still work to be tested
Not yet
ChatGPT → GitHub causal linkageWe have separate internal analyses. We should not describe them as a proven end-to-end lineage system.
future test
Not yet
Productivity or ROI from code activityCommit volume, line changes, merge rate and AI signal do not by themselves establish economic value.
needs outcome data
Not yet
Automated accounting conclusionThe GitHub classifier can create a candidate and evidence queue. Policy, project facts, cost basis and professional judgment are still required.
needs methodology

5. Where we go next

The next dog-food steps are deliberately incremental: test whether the two populations can be joined where evidence is strong, add reliable cost and project context, and see whether human review gets materially faster or more complete.

Next experiments
Questions, not claims

Why this matters for TokenOps

For us, TokenOps is becoming less about producing a bigger AI dashboard and more about building a disciplined path from activity → classification → review → evidence.

Our internal tools are still narrow. That is useful. They let us test the mechanics on real data, expose what the data cannot tell us, and earn the right to add the next layer only where it improves a decision.

Dog food the evidence before selling the conclusion.

Start with what the data actually supports.

Method note

How to read the internal numbers

The GitHub figures above come from one internal dashboard reporting window. They are presented as examples of the population the tool analyzed, not as productivity benchmarks or external claims.

  • Line changes can be heavily affected by generated files, dependencies and large data changes.
  • AI explicit / inferred / not detected describes the presence of detectable signal in the source data; “not detected” does not prove that AI was not used.
  • Yes / review / no is an internal classification output for the work item. A supportable accounting conclusion requires the relevant project, policy, phase, feasibility, intent and cost evidence.
  • ChatGPT estimated cost and value tiers are working analytic fields used in the internal audit dashboard, not audited spend or independently verified value measures.