Engineering delivery assurance
Know what’s really done.
Work trackers record what people say is done. Yakini checks it: for each item marked done, it reads the code that shipped, runs the tests and follows the delivery record, then gives every acceptance criterion a verdict, with the evidence behind it.
- Every citation checked against your code
- Hosted, dedicated or self-hosted
- Your choice of models, self-hosted too
Works with the tools your teams already use
- Jira
- GitHub
- GitLab
- Azure DevOps
- Linear
- Bitbucket
- Jenkins
- CircleCI
- Argo CD
- Kubernetes
- HCP Terraform
- LaunchDarkly
- Unleash
- Datadog
- Sentry
- Grafana
- PagerDuty
- TestRail
- ServiceNow
- Slack
- Microsoft Teams
Why Yakini
A status is a claim. Yakini looks for the evidence.
A ticket moves to Done when someone moves it. Whether the behaviour exists, works and reached the people it was for is a separate question, and the answer is spread across repositories, pipelines and deployments.
Done isn’t delivered
An item can close with a criterion left out, a test that checks nothing, or a change that never reached production.
Evidence is scattered
The code, the tests, the pipeline and the deployment live in different tools, looked after by different people.
Checking by hand doesn’t scale
Reading code and pipelines for every closed item takes time that leaders and reviewers rarely have.
Sprint 47 · Payments
Five items marked Done
PAY-655
Save cards for faster checkout
Done in the trackerSupportedImplemented, tested in the lab, released in rc-3 and running in production.
PAY-412
Retry failed card payments
Done in the trackerPartially supportedTwo of three criteria are supported; nothing sends the final email.
PAY-771
Payout result callback handling
Done in the trackerContradictedImplemented, but only partly tested, and release candidate rc-3 doesn’t contain it.
PAY-702
Refund status webhooks
Done in the trackerNot foundNo handler for refund events in the repositories searched.
PAY-719
Settlement report export
Done in the trackerUnverifiedThe reporting repository was out of reach, so Yakini abstains and says why.
How it works
From a status change to a verdict you can check.
Yakini audits each work item declared done, criterion by criterion, and publishes only what survives its deterministic checks.
Step 01
A claim arrives
A tracker sync or webhook records the change. Yakini reads the claim, from a status change, a comment or a percentage, and splits the acceptance criteria.
Step 02
An audit starts
When an item moves to Done, or another trigger you set fires, the audit queue applies your evidence policy, repository scope and budget.
Step 03
The auditor investigates
It reads the code at the exact commit that shipped, traces the path to the behaviour, runs tests in an isolated lab and checks the delivery record.
Step 04
Deterministic checks
Every citation and trace is validated against the repository, your policy is applied mechanically, and every contradiction is independently challenged.
Step 05
A fair publication
Definitive verdicts wait for a person’s approval by default. The engineer sees the findings first and can challenge them, and each audit yields a signed proof package.
Assurance
Rules, not a model, decide what is published.
A verdict is never taken from a model directly. It has to rest on evidence that deterministic checks have validated, and survive a challenge.
Pinned to the commit that shipped
The auditor reads the code at the exact commit that shipped, not the latest branch, and every citation is checked against that source before it can support a verdict.
Tests that have to catch a bug
Existing and generated tests run in an isolated lab. A test counts as evidence of behaviour only when it fails against a deliberately broken copy of the code.
Every contradiction challenged
Before a Contradicted verdict is published, an independent challenger tries to refute it. Unresolved disagreement ends as Unverified, with the reason.
People stay in charge
Definitive verdicts wait for a person’s approval by default. Findings go to the engineer first, who can add context or challenge them.
Proof anyone can check
Each audit yields a proof package, PDF for people and JSON for systems, signed so that any change shows.
Delivery dimensions
“Done” is six questions, not one.
Yakini splits every claim of Done into delivery dimensions, from the code to the running system. The first three come from the investigation and are checked against your policy; the rest are decided from recorded delivery facts, never by a model.
Implemented
The behaviour exists in the code at the audited commit.
PAY-771, sample audit:
SupportedIntegrated
Merged into the integration branch and reachable from an entry point, such as an API route.
PAY-771, sample audit:
SupportedValidated
Tests that exercise it pass, and they fail against a deliberately broken copy.
PAY-771, sample audit:
Partially supportedRelease ready
The release candidate’s build contains the commits, and its CI runs and quality gates passed.
PAY-771, sample audit:
ContradictedDeployed
The deployment in effect contains it, and flags serve it to the people the claim is about.
PAY-771, sample audit:
ContradictedOperational
Approved runtime checks pass in the target environment after the deployment.
PAY-771, sample audit:
Not required
Five verdicts
Every criterion gets one of five verdicts.
Each has its own shape as well as its colour, so it reads the same in greyscale, to colour-blind readers and to screen readers. Unknown never looks like done, or like failed.
- Supported
- Sufficient evidence establishes the claim under the applicable completion policy.
- Partially supported
- Some required behaviour is established, but material obligations remain.
- Contradicted
- Positive evidence shows the claimed behaviour or condition is false.
- Not found
- No supporting implementation or evidence was located within the recorded search scope.
- Unverified
- No reliable determination is possible. This is an abstention, not a finding that work is missing.
A work item is supported only when every criterion it counts is supported. A contradiction is never published without an independent challenge, and definitive verdicts can be held for a person’s approval before they’re published.
The product
The evidence, not a summary.
Every verdict opens onto what it rests on: the code at the audited commit, the tests the lab ran, the delivery record and the challenge. Auditors can follow every step.
Release readiness, feature by feature.
Every promised feature in a release candidate, with its verdict, its delivery evidence and where the build is running. People make the go or no-go call; Yakini attaches the evidence to whatever they decide.
- Builds checked by git ancestry, CI runs and quality gates
- Deployments and feature flags checked for the audience a claim is about
- A go/no-go pack to export, with the evidence behind it
For every role
The same evidence, shown the way each role needs it.
Leaders see what the evidence supports; engineers see their findings first and can answer them.
- Executives and directorsPortfolio delivery assurance: what was declared done against what the evidence supports, by project and team.What they see
- Engineering managersThe team’s delivery for the sprint, open findings and the items still in their review window.What they see
- EngineersYour findings first, private self-checks of a branch before you declare it done, and challenges.What they see
- Release managersRelease readiness: every item in a candidate, its verdict and its delivery evidence.What they see
- Project managersConfidence in each commitment, scope changes as they happen, the roadmap and stakeholder updates.What they see
- Auditors and assurance reviewersThe audit workspace: the plan, every step and tool call, citations, traces, tests and the challenge.What they see
Principles
Fair to engineers, by design.
Yakini publishes findings about work people did. The rules for doing that fairly are built into the product, not left to policy.
Evidence, not status.
A verdict cites code at a commit, an executed test or a delivery record. Claims in tickets are things to check, never evidence.
Abstain rather than guess.
When evidence is missing or out of reach, or the budget runs out, the verdict is Unverified and says why.
Fair to engineers.
Findings stay private to the assignee during a review window. Engineers can add context and challenge any finding.
About delivery, not people.
Yakini never ranks, scores or compares individuals. It reports on work, not on the people who did it.
Security and control
Built to be trusted with your source code.
Isolation, encryption and control over models come first, in every deployment option.
Isolation by the database
PostgreSQL row-level security on every tenant table, and storage partitioned by organization.
Credentials encrypted per organization
Each organization’s credentials are encrypted with its own data key, and never shown again once saved.
Your choice of models
Choose the provider and model for each task, including models you host yourself. Yakini trains no models on your code.
Code that stays in your network
With a private runner, repository code and test execution stay inside your network.
Identity and access
Single sign-on with OIDC or SAML 2.0, SCIM 2.0 provisioning, MFA, and 13 roles over 44 permissions.
A tamper-evident security log
Security events go to an append-only, hash-chained log whose chain you can verify at any time.
Four ways to run it
The same product and the same controls in each.
- Hosted
- Hosted with a private runner
- Dedicated
- Self-hosted
Integrations
Works with the tools your teams already use.
Claims come from your trackers; evidence comes from source control, pipelines, deployments, feature flags, observability and test management. Anything else can send signed events.
Work tracking
Where claims come from: status changes, comments, percentages and the acceptance criteria.
- Jira
- Azure DevOps Boards
- Linear
- GitHub Issues
- GitLab Issues
- YouTrack
Source control
The code at the exact commit that shipped, and the pull requests that brought it in.
- GitHub
- GitHub Enterprise Server
- GitLab
- Bitbucket
- Azure Repos
CI/CD and builds
Pipeline runs with their quality gates and test reports, and builds with their digests.
- GitHub Actions
- GitLab CI
- Azure Pipelines
- Bitbucket Pipelines
- Jenkins
- CircleCI
Deployment
What is running in each environment, and which build it came from.
- GitHub environments
- GitLab environments
- Argo CD
- Flux CD
- Kubernetes
- HCP Terraform
Feature flags
Whether a change is switched on, and for whom: targeting rules are checked against the audience a claim is about.
- LaunchDarkly
- Unleash
- OpenFeature
- Azure App Configuration
- ConfigCat
- Split
Observability
Runtime observations, for criteria that need evidence from a running system.
- Prometheus and Alertmanager
- Datadog
- Sentry
- New Relic
- Grafana
- Azure Monitor
Questions
What security and engineering leaders ask first.
Something else? Ask us, or read about security and AI governance.
Can Yakini change anything in our systems?
The auditor can’t: it works with read-only tools, under hard budgets for tool calls, tokens, time and cost. Yakini writes back to your tracker only where you turn that on, such as comments or issues, and those can wait for an approval.
Where does our source code go?
Where you decide. With a private runner, repository code and test execution stay inside your network; only the audit record and result, reduced by your outbound policy, leave it. Yakini can also run as a dedicated deployment or in your own environment.
Which AI models does Yakini use?
The ones you choose, task by task: Anthropic Claude, OpenAI, Azure OpenAI, Z.ai, GitHub Copilot, any OpenAI-compatible API, or models you host yourself. Yakini trains no models on your code, and your organization decides which providers may receive source code.
Can a model’s answer become a verdict on its own?
No. Deterministic checks validate every citation and trace, apply your completion policy and work out confidence from the evidence; every contradiction faces an independent challenge; and definitive verdicts wait for a person’s approval by default.
Is it fair to the engineers whose work is checked?
Findings go to the assignee first and stay private to them during a review window, while they add context or challenge them. Yakini never ranks, scores or compares individuals. Our principles
What happens when the evidence isn’t there?
The verdict says so: Not found when nothing was located in the recorded search scope, and Unverified when no reliable determination is possible, with the reason. Unknown never looks like done, or like failed.
How is Yakini priced?
Pricing is tailored to each organization and set out in a written proposal, once we understand how you would deploy and use Yakini. How pricing works
See Yakini with your own questions.
We’ll walk you through Yakini with a sample organization, show the evidence behind each verdict, and answer your questions about deployment, security and models.
- Hosted, dedicated or self-hosted
- Your choice of models, self-hosted too
- Pricing set out in a written proposal