Trading as git
Every trade in Qoc is a commit you approve — a diff with a message, a history you can revert, and an audit trail that's a first-class feature of the desk.
If every trade is a commit, then your trading history is a repository — diffable, auditable, and reversible in ways that a spreadsheet or a brokerage statement never could be.
The analogy that drives the design
Git made software development auditable by treating every change as a discrete, named, reviewable unit. Before you merge a pull request, you read the diff. After it's merged, the history tells you who changed what, when, and why.
Qoc applies the same model to trading. A proposal is a diff: here is what the desk looks like now, here is what it will look like if you approve this trade, here is the rationale. Approving is committing. The history of your desk is a sequence of commits you can inspect, annotate, and compare.
What a proposal looks like as a diff
When an agent produces a proposal, it writes a structured file to orders/pending/. That file describes the instrument, direction, size, the guard rules it passed, and the agent's rationale. Once approved and executed, the file moves to orders/history/ and the desk snapshot is updated.
The transition — pending to executed, with before-and-after snapshots — is what makes each trade a diff. You can run qoc log to see every trade as a one-line entry, and qoc show to expand any entry into its full context.
Reading your trade history
qoc log
# 2026-05-28 APPROVED BUY AAPL 50 shares @ market [guard: pass]
# 2026-05-21 APPROVED SELL TSLA 25 shares @ 187.40 [guard: pass]
# 2026-05-14 REJECTED BUY NVDA 200 shares @ market [reason: size]
qoc show 2026-05-28Rejected proposals are part of the history too
When you reject a proposal, that rejection is recorded — with any feedback you provided. The next time the agent looks at the same opportunity, it can read that rejection and understand why you passed. Over time, the rejection log becomes a body of implicit constraints that shapes how the agent thinks about your desk.
This is one of the more underappreciated aspects of the model: the agent learns from your decisions not through fine-tuning or configuration, but by reading its own history.
History is tamper-evident by default
Qoc's workspace history uses the same content-addressed storage model as git. Once a trade is committed, the record can't be quietly edited — any modification changes the hash and breaks the chain.
For regulated traders, this property is important: the audit trail isn't a best-effort log, it's a structural guarantee built into how the workspace stores data.
Git concepts mapped to the trading desk
| Git | Qoc trading desk |
|---|---|
| Working tree | Current desk state — positions, balances, open orders |
| Diff / patch | Proposal — what changes if this trade executes |
| Commit | Executed trade — approved proposal plus before/after snapshot |
| Commit message | Agent rationale attached to the proposal |
| Pull request review | Inbox proposal review — approve or reject |
| Revert commit | Close or offset a position, referencing the original trade |
| git log | qoc log — full history of proposals and their outcomes |
| git blame | qoc show — who (or what) proposed a trade and when |
Revert: closing a trade with context
Reverting in git undoes a commit. In Qoc, the equivalent is closing or offsetting a position — and when you do it, you reference the original trade. This linkage means the history is coherent: you can trace an open position back to the proposal that created it, the research note that informed it, and the guard rules that were in effect at the time.
If the position was unprofitable, that context is preserved too. The agent can read it. You can read it. Six months from now, when you're trying to understand a pattern in your results, the history is all there — structured, searchable, and honest.
Use issues to annotate your history
The issues/ directory in your workspace works like GitHub issues attached to a repository. You can open an issue to track a thesis ('watching AAPL into earnings'), link proposals to it, and close it when the thesis resolves.
Issues give your trade history narrative structure — not just what you did, but why you were paying attention to it in the first place.