Project context changes as a team learns: instructions improve, files are replaced, and new Knowledge becomes relevant. Kestrel One records those changes as revisions instead of rewriting the past underneath existing work.
What a revision contains
A context revision identifies the Project instructions, private files, selected organization Knowledge, allowed Apps, Environment reference, and relevant policy references available for a new turn. Each accepted change creates a new immutable revision.
Why each turn records one
When a new turn begins, Kestrel One attaches the current revision to it. Later, a reviewer can distinguish what the agent actually received from what the Project contains today. Earlier Threads do not pretend they used files or instructions added afterward.
A simple example
If a teammate replaces requirements-v1.pdf with requirements-v2.pdf, the next turn uses the new revision. A previous result still points to the revision containing requirements-v1.pdf, so its reasoning can be reviewed honestly.
Who may change context
Project role, resource ownership, and organization policy determine who may update each input. Accepting a context change records the authorized actor and new immutable revision.
Inspect a revision
Compare the revision attached to a turn with the Project’s current revision. Reviewers should be able to identify changed instructions, files, Knowledge, Apps, and Environment references.
Operational implications
Replay and review use the historical revision. Earlier Threads do not pretend to have used later context, and removing current access does not rewrite the evidence for an already completed turn.