GitHub - eighttrigrams/us-vs-them: Line-level provenance for text under agentic editing — who wrote this line, us or them? — derived from version history, not from markup in the file. · GitHub
/" data-turbo-transient="true" />
Skip to content
Type / to search
Sign in<br>Sign upAppearance settings
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
eighttrigrams
us-vs-them
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>43 Commits<br>43 Commits
src/et/uvt
src/et/uvt
test/et/uvt
test/et/uvt
.gitignore
.gitignore
Makefile
Makefile
README.md
README.md
deps.edn
deps.edn
title_image.png
title_image.png
View all files
Repository files navigation
Us vs. Them
Line-level provenance for text under agentic editing — who wrote this line, us or<br>them? — derived from a text's version history. Use it as library or as CLI tool.
The problem
With agentic coding and editing, provenance becomes a pertinent question. Text a<br>human wrote or edited should be considered close to sacred: an agent should<br>be hesitant and have a very good reason to touch it. Slop another agent has produced,<br>on the other hand, is completely up for grabs.
A use case for this: Take a mostly vibecoded app in which you want to establish<br>some corners in the code where you want to assert your ideas and ownership.<br>You surely don't want another agent bulldoze over this piece of code<br>in the next session.
Another use case: the README.md, originally generated, where you rewrite<br>the opening paragraphs. The agent should feel free to redo or append parts<br>further downwards but should really think twice changing anything in the opener.
How it works
The main constraint under which this should work is that this should not require<br>for text to be marked up specifically for that. Omnipresent plain text (markdown)<br>should be supported as is.
The only thing to leverage then, is that each new version of a text is created<br>under identifable authorship - of either a human or an agent.
The output of an evaluation over a given text is a set of ranges — "islands" of<br>human-authored lines inside a "sea" of machine generated text. Technically based on simple diffing,<br>this is the guiding metaphor for development of the algorithm. We don't want to track authorship<br>of individual lines only, but of meaningfully coherent pieces of text.<br>So joining, splitting apart, and dilution of authorship are behaviours<br>to be factored in, also in such a manner that we don't<br>converge in full sea or full island.
Usage
Using us-vs-them as CLI tool requires bbin for a local install.
make install
A git repository is already a history of versions each carrying a provenance<br>marker — every revision of the file, in order, with the author of the change that<br>made it.
To use it anywhere inside a git repository:
us-vs-them --ours dan@eighttrigrams.net README.md
This yields a listing like
1-3 0.00<br>4 1.00<br>5-7 0.00<br>8-20 0.46<br>21-164 0.00
where 1.0 means fully human authored range.
0.46 means originally human authored range, modified by agents to a certain degree.
0.00 means fully agent authored.
Parameters are:
--ours: these are the humans, everonee else is considered an agent
--theirs: these are agents, everyone else is considered human
Name whichever side is the shorter list.
Passing both arguments at the same time will be rejected.
Development
make test
Behaviour
The best way to understand the behaviour is to have a look at<br>caution_test.clj.
About<br>Line-level provenance for text under agentic editing — who wrote this line, us or them? — derived from version history, not from markup in the file.<br>Resources<br>Readme<br>Activity<br>Stars<br>0 stars<br>Watchers<br>0 watching<br>Forks<br>0 forks<br>Report repository
Releases
Packages
Contributors
Languages
You can’t perform that action at this time.