Who approved what, and when

The log records an actor by name rather than by a link to a user account, and that single decision is what makes the rest of it work.

A person is an actor. So is the in-app agent. So is a key minted for your own AI. So is a rule your workspace wrote. A schema that recorded approvals as a user identifier would have had to invent something for the last two, and whatever it invented would have been a lie by omission.

It also means the record outlives what it describes. A change request can be edited or superseded; the log of what happened to it stays readable on the entity's own activity feed. And revoking a credential does not un-write anything it did.

Every move a change makes is a row, not only the approval. One for writing it, one for each edit, one for the approval, one for the apply, and one for each way an apply can end: refused by the platform, rolled back because a sibling in its batch failed, or written off by hand after it stopped answering. Rejections and undos are rows of their own.

Each row names who acted. For an approval it names two more things: which authority cleared it, and whether the approver was the same actor that drafted the change.

That second one is the field most worth knowing about. A key approving its own work is a different fact from a person approving it, and a record that flattened the two would be worse than no record — it would read as oversight where there was none. So the gate says it in words, and the row keeps it.

A person. Approving in the app records that user against the row. This is the case people assume is the only one.

A key. A credential minted with the approve scope may approve, including a draft it wrote itself. It is opt-in at the mint, off by default, and the in-app agent never holds it.

A rule. An approval rule your workspace wrote can clear a draft in place of a person. The row names the rule, and so does the card at the gate.

Two authorities, in the framing that matters: approved by you, or by a rule you wrote. The key case is a version of the first — you minted the credential and chose its scopes — and the record distinguishes it so that the choice stays visible after the fact.

The arrangement, stated once: your connections read your accounts, a change is written as a draft on the record with the state it would change from and the checks it passed, applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

Four questions, in this order, and each one narrows the next.

What changed on the entity? The activity feed on the entity is the narrow view: every row that touched this campaign, in order, with what it moved and from what.

Which authority cleared each one? If everything was a person, the question is about judgement. If a rule cleared them, the question is about the rule, and the rule's own definition is the next thing to read rather than the rows.

Was the approver the actor that drafted it? A run of self-approved rows from one credential is a finding regardless of whether any individual row was wrong.

Was it us at all? Where a platform exposes its own change history, it says who changed what, when, from where, and exactly which fields moved. A change that does not appear in Tempio's log and does appear in the platform's was made outside Tempio, which is a different conversation and a common one on accounts several people touch.

It will not tell you whether a change was a good idea. It records the decision and the authority, not the outcome; pairing it with the daily counts either side of the change is how you get from one to the other, and that pairing is a thing you do rather than a thing it does.

And it will not summarise itself. Reading a month of rows is reading a month of rows. The practical response is to make the volume legible in the first place: a rule with a job narrow enough that a change in how often it fires is noticeable, rather than one clearing sixty drafts a week that nobody reads.

Three habits, none expensive.

Name credentials after the thing holding them. "The nightly reporting job" is an actor you can reason about. A generic name is a row you have to go and identify.

One credential per client. A shared one makes every row ambiguous about who acted and makes the last-used stamp meaningless.

Give rules narrow jobs. A rule that clears one recurring decision leaves a legible trail. A rule that clears everything leaves a trail that says nothing except that the rule was on.

Write an approval policy for ad changes is where the second authority gets written, Review a batch of campaign changes is the reading done before the row exists, and Audit an ad account after a bad week is the procedure that uses all of it at once.

What a week looks like when all of it is on the record is A week of ad changes on the record.