Illustrative report from a fictional expense app. These people, events and amounts are made up. Here is where expenses stand this week.
Three pull requests touched expenses between Monday and Thursday. The largest changed who approves them: anything over the $500 limit now routes to the project owner instead of the line manager. Sam opened it, Dana approved it on Tuesday afternoon, and it shipped with the Thursday release.
An active verification check flagged the released approval policy after the production push, because the doc still named the line manager. A correction was proposed and its owner approved it. The paragraph now matches the checked routing rule. That checks this claim at this revision; it does not establish that the whole policy is right.
That check was not only the approvals page. Fourteen other documents mention who signs off on what, and I re-tested all of them against the code on Thursday night. Eleven were already right. Two described a routing rule that has not existed since March. One contradicted itself in consecutive sentences, and I have drafted a correction rather than editing it quietly.
The change had one consequence nobody wrote down. Project owners do not have the finance dashboard, so approvals now arrive by email and come back a few hours slower. Finance thought Wednesday's queue looked stuck. It was not stuck, it was in somebody's inbox. I left a note on the rollout thread so it does not get raised again next month.
Two things are waiting on a person.
Priya's Berlin flight is $1,240. I found its receipt and prepared the claim against the EU expansion project, but I have not submitted it. That action is set to Ask, so the request has been waiting for you, the signed-in user, in this conversation for two days. The turn is parked and can resume when you answer. Your yes lets me attempt the submission; any later finance approval belongs to the expense app.
The second is smaller. You asked to split a $310 team dinner across two projects, and the released policy does not cover split allocations. I have asked you how to allocate this claim rather than guessed. Your answer applies to this request; it does not silently change the policy for everyone else.
Neither request is finished. The flight is waiting for permission to submit, and the dinner needs an allocation. I would rather name those two gaps than call either claim approved or promise a reimbursement date.
Everything else ran without asking. I matched forty-one receipts to projects, chased nine that were missing, and filed sixty-three expenses under the limit, every one inside policy and every one recorded. The audit trail has all of them, including the ones I was allowed to do without asking. Those are the interesting ones, because they are the decisions nobody watched.
One turn did not go cleanly. Tuesday's expense review survived a runtime restart and recovered from its last recorded round. A separate submission lost its open page while the API request was in flight. That request was not retried, and I recorded its outcome as unknown rather than reporting it as filed.
The next step is to check the claim in the accounting system before trying another submission. Recovering the conversation tells us where the turn stopped; it does not establish whether a separate backend committed a transaction. That is an inconvenient distinction, and less inconvenient than filing the same expense twice.
Last month cost $412 across 2,140 conversations, about nineteen cents each. Filing was the busiest skill at thirty-eight per cent of every action taken, and the cheapest by far, because most of them end in a single step.
Two people are worth a look. Marcus has filed the same hotel three times in five weeks, which usually means the duplicate warning is not landing. Ines has asked where her reimbursement is four times, which usually means the status email is not arriving.
One recommendation. If split allocations should follow a standing rule, have the policy owner write and release that rule. For now, I still need your answer on this dinner. A missing policy is a question to resolve, not permission to make one up.
Illustrative report from a fictional expense app. These people, events and amounts are made up. Here is where expenses stand this week.
Three pull requests touched expenses between Monday and Thursday. The largest changed who approves them: anything over the $500 limit now routes to the project owner instead of the line manager. Sam opened it, Dana approved it on Tuesday afternoon, and it shipped with the Thursday release.
An active verification check flagged the released approval policy after the production push, because the doc still named the line manager. A correction was proposed and its owner approved it. The paragraph now matches the checked routing rule. That checks this claim at this revision; it does not establish that the whole policy is right.
That check was not only the approvals page. Fourteen other documents mention who signs off on what, and I re-tested all of them against the code on Thursday night. Eleven were already right. Two described a routing rule that has not existed since March. One contradicted itself in consecutive sentences, and I have drafted a correction rather than editing it quietly.
The change had one consequence nobody wrote down. Project owners do not have the finance dashboard, so approvals now arrive by email and come back a few hours slower. Finance thought Wednesday's queue looked stuck. It was not stuck, it was in somebody's inbox. I left a note on the rollout thread so it does not get raised again next month.
Two things are waiting on a person.
Priya's Berlin flight is $1,240. I found its receipt and prepared the claim against the EU expansion project, but I have not submitted it. That action is set to Ask, so the request has been waiting for you, the signed-in user, in this conversation for two days. The turn is parked and can resume when you answer. Your yes lets me attempt the submission; any later finance approval belongs to the expense app.
The second is smaller. You asked to split a $310 team dinner across two projects, and the released policy does not cover split allocations. I have asked you how to allocate this claim rather than guessed. Your answer applies to this request; it does not silently change the policy for everyone else.
Neither request is finished. The flight is waiting for permission to submit, and the dinner needs an allocation. I would rather name those two gaps than call either claim approved or promise a reimbursement date.
Everything else ran without asking. I matched forty-one receipts to projects, chased nine that were missing, and filed sixty-three expenses under the limit, every one inside policy and every one recorded. The audit trail has all of them, including the ones I was allowed to do without asking. Those are the interesting ones, because they are the decisions nobody watched.
One turn did not go cleanly. Tuesday's expense review survived a runtime restart and recovered from its last recorded round. A separate submission lost its open page while the API request was in flight. That request was not retried, and I recorded its outcome as unknown rather than reporting it as filed.
The next step is to check the claim in the accounting system before trying another submission. Recovering the conversation tells us where the turn stopped; it does not establish whether a separate backend committed a transaction. That is an inconvenient distinction, and less inconvenient than filing the same expense twice.
Last month cost $412 across 2,140 conversations, about nineteen cents each. Filing was the busiest skill at thirty-eight per cent of every action taken, and the cheapest by far, because most of them end in a single step.
Two people are worth a look. Marcus has filed the same hotel three times in five weeks, which usually means the duplicate warning is not landing. Ines has asked where her reimbursement is four times, which usually means the status email is not arriving.
One recommendation. If split allocations should follow a standing rule, have the policy owner write and release that rule. For now, I still need your answer on this dinner. A missing policy is a question to resolve, not permission to make one up.
