Auditing changes

Most access questions are answered by reading the columns already on screen. Every list in the panel records who did the thing and when.

1. On the Dashboard, the Users table carries Created At and Created By, so you can see who added an account. Add a Status or Organizations filter to narrow it.
2. The Roles tab shows Created At and Created By for each role, next to what it Has Access To.
3. In Organisations, the People table on an organisation shows Added By and Added At for every member.
4. Inside a project, the Project members table shows the same two columns, which is the trail that matters most: it is project membership, not the role, that decides what a client can see.
5. On the GitHub tab, the connected card names who connected the repository and when.

For the records themselves rather than the people:

• Title and description edits on requests, issues, feature requests and change requests are kept as revision history. The wording someone signed off on survives being rewritten, and the same history covers edits made through MCP as well as edits made in the browser.
• Sorting a request into an issue or a feature or change request is stamped with who sorted it and the reason they gave, if they gave one. That is usually enough to settle why a request became one thing rather than another.
• Assignment and status changes notify the people affected rather than sitting quietly in a log, so the person who now owns the work finds out because they were told.