Project knowledge, intact
What the client said, what was promised, what was not — captured from all channels, reconciled, on record. A single source of truth for the engagement.
The unclaimed layer
Coding with AI is table stakes now — every company can do it, so it wins no one an edge. The advantage is in applying AI to the management layer, where outcomes and margin are decided.
AI should amplify not just engineers — but also the people who manage them and own the outcomes.
The problem, in delivery terms
Project knowledge lives in calls, documents, emails, chat threads and people's heads — distributed across everything, owned by no one.
The result: rework, scope creep, broken commitments and missed deadlines. What the client asked, what we promised and did not promise, the dates, the scope, the things said only by hint — today everyone on the team holds a different piece of it, and nobody holds it all. Even an experienced manager has human limits: gets tired, gets used to things, gets distracted, hears what's convenient.
The gap in the current answer
Faster code delivery is necessary. It is not sufficient.
The IT-services model that sells billable hours is being squeezed by AI — and this isn't a temporary dip. Companies are responding by speeding up development with AI and, increasingly, selling an outcome rather than a rate. But an outcome is won or lost not in coding speed, but in how the engagement is run — planning, risk, client knowledge, decisions. That's where AI adoption stalls and margin leaks. Faster code does not close that gap.
Current investment
Architects & engineers on AI
Code is generated faster. Technical quality improves. Delivery velocity increases.
The gap
Management layer
DMs, field leads and account managers. Currently see AI as a demo. Not enabled, not measured.
Where outcome lives
Client results & margin
Commitments kept. Scope defended. Risks surfaced early. Rework eliminated. These are management outputs, not engineering ones.
The gap is the distance between faster code and better client outcomes. The opportunity is to own that layer.
The offering
A capability that moves outcome metrics, not just velocity.
Contradiction & risk detection
Documents, transcripts and decisions cross-checked continuously. Conflicts flagged before they reach a signature or a client call.
AI-assisted decisions
Planning, risk assessment and scope management supported by a system that is consistent and does not get tired, distracted or deferential.
Measurable outcome layer
Scope compliance, commitment tracking, open-question age. Management KPIs that map directly to client outcomes and margin — not just velocity.
Where a human slips
What the system holds
Scattered files. Decisions land in SharePoint, email, Confluence, Teams and local drives; no one knows where to look.
One place to ask. The system pulls from all sources into one knowledge base; the answer is always in the same place.
Channel drift. One thing on the call, another in email, a third in chat; the new person only reads chat.
All channels, one record. Calls, emails, docs and chats ingested together; everyone sees the same timeline.
Commitments. "We promised something on that call — what, exactly?"
On record. Every promise, denial and agreement captured with speaker, date and source.
Document overload. The client sends 30 files; people skim, miss half, fill gaps with assumptions.
Read, not skimmed. The system reads everything, surfaces facts, patterns and contradictions.
Scope boundary. What we did not commit to blurs, then becomes free work.
Out of scope, on record. "Not promised" is stored as a fact, not a gap.
The unsaid. Things said by hint or in passing evaporate by the next meeting.
Noted and followed up. Captured as an open question and chased to an answer.
Contradiction. Two documents disagree; nobody notices until it costs money.
Flagged. When two sources disagree, it's flagged, not averaged away.
Trust of source. A guess and a client fact read the same in a hurried summary.
Sourced and rated. Each claim tagged confirmed / assumption / open, with its source.
How it works
One system across all channels. Always on.
Sources
Calls, documents, emails, chats — all channels, all formats.
→
Captured
Facts, commitments and open items extracted and sourced.
→
Knowledge base
Each claim labelled confirmed / assumption / open, with date and origin.
→
Signals
Contradictions, risks and open questions — proactively or on demand.
knowledge base · entry #312
- source
- call-2026-07-14 · 00:41:22
- project
- client-portal-migration
- speaker
- client
- claim
- "We need the integration live before the October go-live."
- axis
- sla · scope
- firmness
- assumed · verbal only
- status
- open · no written confirmation
- linked to
- SOW §3.2 · email 2026-07-08
- ⚠ conflicts
- document v2 — end date listed as November
Transcript → structured facts
Each claim with speaker, attribution type (said / agreed / denied / relayed), source reference, timestamp to the second, project binding, axis (SLA, scope, contract, tech…), firmness label and conflict flag. The raw source is preserved verbatim alongside.
Firmness labels
Written confirmation, verbal only, or our own assumption. The system never treats a call mention as a signed commitment.
Provenance on every claim
Any fact traces back to its source — call, document or email — with a timestamp.
Contradiction detection
When two sources disagree, the system flags it instead of silently overwriting. The last word does not automatically win.
Accumulation over time
Every call and document adds to a living history. Anyone joining mid-engagement gets structured context instead of a folder of files.
DM asks the system
"What did the client say about SLA across the last three calls?"
Summary with exact quotes, dates and speakers — across all calls, not just the most recent.
"What did we commit to in June that hasn't been delivered yet?"
List of commitments with current status, source and date of agreement.
"Which client questions have been open for more than two weeks?"
Ranked list with age, context and the last mention in any channel.
"Has the client ever mentioned competitors or alternatives?"
All mentions across all channels, with context and sentiment where detectable.
The system raises a signal on its own
Document v3 describes scope wider than what was agreed on the call.
Flagged with both sources, before the document reaches the client.
Client referenced a commitment in email that exists in no document or transcript.
Raised as an unverified claim — risk of dispute surfaced before the next call.
Three open questions have had no response for 30+ days.
Flagged before the next meeting so the DM goes in prepared.
Two versions of the SOW carry different contract end dates.
Caught before signature.
Onboarding & handover
"I'm taking over this account. Walk me through the last three months."
Structured brief: key decisions, open items, commitments, risks — ready in minutes, not days.
By the numbers
A production system — in numbers and catches.
- 31
- meeting transcripts captured verbatim
- 415
- observations, each tied to a source
- 1,600+
- claims labelled confirmed / assumption / open
- 44
- open questions actively tracked
- 54d
- oldest open question — still tracked
// production system; figures are illustrative and disclose no real commercial data
Margin
A scope document said "6+ member" delivery pod; a call recording from the week before had fixed it at ≤5 (client budget for five). The conflict was flagged before the wrong number reached headcount planning.
Pricing
A payment schedule totalled 18 × $70K = $1.26M, silently omitting a "first month free" discount agreed on the call (effective ≈ $66.7K/mo). The gap was caught before signature.
SLA
Requirements said SLA recalibration = 3 months; the contract draft said 1 month. Flagged, argued out, fixed before anyone signed.
Dates
A contract draft had two different expiry years in different sections. Caught and fixed.
Human·loop
A document "Owner" field named two different people in two versions. The system stopped and asked instead of picking one.
Each catch is a risk that didn't make it to the invoice or the client call. How I build and run systems like this — at dobryakov.net →
Why this is a winning move
Differentiation
Every competitor is certifying coders. That is table stakes, not a moat. An outcome-linked management capability is a moat: harder to copy, more visible to clients.
Margin & utilization
Fewer scope overruns, less unbilled rework, better commitment tracking across the portfolio. The financial impact is direct and measurable at the account level.
Outcome-based revenue
Selling outcomes requires the capability to guarantee them. AI-native delivery management is the operational layer that makes outcome-based commitments credible, not aspirational.
Governance by design
Data isolation
Every source is marked trusted (from client) vs our own hypothesis; untrusted by default. Client data stays in its authorized boundary.
Separation of concerns
What the system does is defined by the operator, not by the content it processes.
Audit trail
Every observation has a source and a date. You can always ask "where did this come from?" and get a straight answer.
Human in the loop
When something is ambiguous, the system stops and asks. It doesn't guess and move on.
Who built this
Delivery background
I manage engagements. I know where knowledge leaks, where commitments blur, where margin disappears. This is not AI applied to a problem I read about. The system solves problems I face every day as a DM — the only way to build something that holds up in daily use.
AI builder
I build and run AI systems, not just use them. The working system behind the numbers above is designed, operated and iterated by me — not delegated. A delivery manager who applies AI to management — not a developer who describes management from the outside. That combination is the mandate.
From a working system to a repeatable practice
How a system like this matures.
Proven
I built and run it
Designed and operated by me on real engagement data. Not a side experiment — it holds up in daily use.
→
Codified
A method, not a habit
It runs on reusable components and written rules, so it isn't locked in one person's head — someone else can pick it up and run it.
→
Repeatable
A teachable capability
The same method, packaged so it can be taught across teams and accounts rather than depending on a single operator.
This isn't a product pitch. It's an example of what I build.
I'm not selling this system — I'm showing what I design and take to production. I put AI into the delivery management layer: planning, risk, commitments, client knowledge. If you're making your delivery function AI-native and need someone to build it and own the outcome, I'm open to a conversation about working together.