TERRANES
EN
Request early access

Security → this page

What we track, and what we don’t

The record covers the work and who was given access to it. It never covers how fast anyone worked. This page exists so that is a commitment you can quote back to us, rather than a preference we could quietly revise.

What the activity log records

A project audit trail, and nothing wider

Every entry belongs to a project. There are no billing events and no identity events in it — those live in Stripe and in the authentication logs, where they belong.

  • Project created, updated, archived; the responsible person changed
  • Members added, removed, role changed, department changed, membership type changed
  • Reports generated and reports shared
  • Invitations sent
  • Comments removed or purged; content reported
  • Files detached or purged
  • Scope items changed; checklist items and quality templates deleted

What no module may ever add

The surveillance features, named

This is a rule in the module contract, not a roadmap position. A module that does any of the following does not ship.

  • Location trails of any kind
  • Activity scoring, productivity scoring, rankings or “most active”
  • Keystroke monitoring or screen monitoring
  • Time tracking
  • Throughput counts per person — how many tasks someone closed
  • Any per-person productivity metric, in any module, ever

The line we draw

Attribution is the record. Throughput is surveillance.

Naming the person accountable is required — a record that says a drawing was released but not by whom is not a record. What is forbidden is the count.

What the product says

Rosa closed the drainage survey on Mon 14 Sep.

What it will never say

Rosa closed 6 tasks this week.

The boundary cases, stated rather than left vague

Resource capacity shows a number per person. Is that a productivity metric?
It shows how many open tasks someone is carrying, which is a capacity signal — what a planner needs in order not to overload a colleague. It is the only per-person number any module may show, and it is a count of what is owed, never of what was produced or how quickly. This is the boundary case, and it is named here rather than buried because naming it is what makes the rest of the commitment checkable.
Does the record show when someone logged in?
Not in the product. Authentication events live in the authentication logs, as security events, and are not surfaced as a view of a colleague’s working hours. Your billing is not affected by them either: the basis is staff membership, never activity — we do not measure whether anyone logged in this month.
Can an administrator turn any of this on?
No. There is no hidden setting, no enterprise tier and no configuration that adds a productivity metric. The prohibition is in the module contract that every module is built against, which is why it can be published as a commitment rather than offered as a default.
Why publish this at all?
Because the buyer is an operations director and the user is a site engineer, and the second one has good reason to assume a new system is a monitoring system. A page they can read in ninety seconds does more for adoption than a paragraph in a contract they will never see.

Check it in the trial.

Thirty days, every module, no card. Open the activity feed on day one and see whether this page is accurate.

Request early access Security and residency