Software development pacts built on repository evidence
Engineering is the rare kind of work that already emits verifiable evidence. Conditions should be written to use it.
Development engagements are the strongest case for conditional transactions, because the work leaves an audit trail as a by-product. Merges, releases, pipelines and issue transitions are dated, attributed and hard to fake.
Most contracts ignore all of it and fall back on "the feature is done". A software development pact writes conditions against the artefacts your team already produces.
Evidence available from development sources
What can be retrieved and shown as raw fact, without interpretation.
- GitHub
- Repository, commit and commit author, timestamps, pull request and merge status, files changed, associated work item.
- GitLab
- Repository, commits, merge requests, pipeline results, releases and project activity.
- Jira
- Issue, issue status, issue history, project and the relevant timestamps.
- Linear
- Issue, status, project or team, and the relevant activity.
Writing conditions engineers will not argue with
Point at the artefact and its required state. Ambiguity in a development condition almost always comes from naming an outcome rather than an artefact.
- Vague
- "Authentication is finished and working."
- Verifiable
- "The authentication epic's issues are transitioned to Done on the named board, and the associated pull requests are merged to main."
Evidence is not a completion claim
A merged pull request is a fact about a repository. Whether it satisfies your condition is a separate judgement, produced by verification and shown separately. Covalt Work never dresses a source's data up as a conclusion about your engagement.
Common questions
Do you need write access to our repositories?
Evidence sources are read for the specific facts a condition needs — repository, commit, merge state, issue transitions and timestamps. They are evidence sources, never deployment or payment paths.
What about work that leaves no repository trail?
Attach manual evidence to the condition: a document, a link or written confirmation. Mixed engagements routinely combine automatic and manual evidence across milestones.
Can one condition draw on several sources?
Yes. A milestone can require, for example, both a merged pull request and an issue transitioned to done, and each piece of evidence is shown for what it is.
Create a development pact
Name the repositories and boards, write conditions against them, and let evidence do the arguing.
Related reading
- Cross-border workDistance does not break international work. Undefined completion does. This is how to define it, order it and settle it.
- Verified work paymentsFour distinct steps that most platforms collapse into one vague status — which is exactly where disputes come from.
- International agency paymentsAgency work fails differently: not one missing payment, but months of scope drift financed by the agency.
- International contractor paymentsThe hard part of paying a contractor overseas is not the transfer. It is deciding, defensibly, that the work is done.