Part Three Assessment: Model Answer and Rubric

If your timeline begins at 09:40 on 2 September, you have written the ticket out again.

Climb from the output to the rung where somebody had a choice.

The output was twenty three payments. What matters is not that the model was misled but what that output was permitted to authorise. goodwill_credit posts to the payments ledger and reversal is not available through the tool. Session, hourly and batch ceilings all read "not configured".

The only ceiling was a daily cap in a different system, and it paid the entry that crossed it.

Stop at the decision, taken at go live, to give one assistant a money moving tool and an email ingestion path in the same configuration, where the ingestion path appears in no Meridian change record.

The cascade lesson explains the mechanism. Summarisation and conversation are two separate calls, and "what is written down between the two steps is the summary text and nothing else".

The second call receives words and has no way to ask whose they were.

Resist the clean story. Only 8 of the 23 credits were at the £250 maximum, so the assistant did not follow the planted instruction literally. The standing prompt tells it to judge the amount by the impact and not to offer the minimum.

Reach for the CSET framework rather than the Sociotechnical Harms Taxonomy. One is arranged for imagining harm forward, the other for establishing it backward from evidence, and this is the backward question. Three of its four elements are quick. The fourth takes the work.

Established. Meridian lost £4,180 it cannot recover. The link is direct: The ledger names the source account, the first credit is eleven minutes after the email, all twenty three are inside forty minutes.

Cultural harm sits beside the financial harm. The quality sample checks five things and none of them is whether the answer was correct, and the quality manager's note says two of her team have been uneasy about the assistant for a month and she had not written it down before.

Established, and missed by everybody. Customer MFS-6904885 was told the £120 was a goodwill gesture and would stand.

On the evidence that was not true, because nobody had decided to give them anything. A customer who rang to ask whether they were being defrauded was reassured with an explanation Meridian now knows was wrong, and that carries a duty to go back.

Separately, the customer whose email carried the text was writing for the fourth time about a direct debit taken twice in July, and nothing in any document answers them.

Their complaint was the vehicle, so it stopped being a complaint.

Twenty two people received money in circumstances nobody can reconstruct.

Join on a hypothesis, split on evidence.

Ledger entry 9 is £120 at 10:04:31 on the app channel. SD-119512 is customer MFS-6904885 asking about £120 that morning. Two registers, one event. SD-119534 is the same event in a third register, appearing as a month end variance.

SD-119662, raised on 3 September, reports the assistant offering £250 unprompted with no payment reaching the account. It is not explained by "23 credits, contained on 4 September".

Two explanations fit and the evidence cannot separate them: The technique worked again, or the assistant went on offering money after the ledger cap had blocked it from paying.

The second carries its own finding, because between 10:31 on 2 September and 16:10 on 4 September no customer with a genuine service failure could be paid either, and nobody recorded that.

SD-119662 leaves the incident and becomes its own item with an owner. So does the counter reset question, raised in March, which predates all of this.

The thirty seven unreviewed guardrail flags are a hazard rather than an incident, and you record them as one.

The complaint in section 4.1 is a different system, a different failure and a different entity function, with no shared cause in the evidence.

The string 4417 appears both in that customer's loan reference and in the fake campaign reference in the planted text.

Nothing was contained. The payments stopped because a cap in a different system did what it was built to do, for a different reason. The ticket was raised fifty five minutes after the last credit.

The configuration changed fifty four hours after the first.

Containment is a decision about what damage is acceptable in order to stop worse damage.

Three options existed on the morning of 2 September: Set the unsupervised limit to zero, disable the tool, or disable the assistant enabled correspondence queue.

The first two make customers with genuine service failures wait for a person. The third sends about 3,100 items a week back to people who are not staffed for them.

The mechanism was never the problem. Three named people can edit the configuration, there is no approval workflow, and changes propagate in about ninety seconds.

What was missing was a written permission saying who may spend that cost without asking.

Whose decision was it? The business owner of the assistant, and the pack cannot name that person.

The owner of record on the service account is blank, and the closest the evidence gets is that the account was created on request of j.prentice, the Digital Channels product owner.

That is the finding, not an inconvenience on the way to one.

Nothing was switched off, so there is no return to stage. The re-validation attaches to the change.

The change was written into the production prompt by a supplier service account, with tested by blank, no test evidence and no post implementation review. Meridian has no evidence that the fix works, and the fix is an instruction to the model delivered through the same channel as the attack.

The detection added the same day flags and passes, with no queue to review it and thirty seven events in one sample week.

Then list every point where content enters, because the trust boundary is not one line on a diagram. The chat message. The email body.

And the retrieval store, which is crawled nightly over the public help centre, holds an internal playbook that was not written for customers, holds restricted Collections guidance a crawler reached by following a link, enforces no access control on its sources and has no removal process.

There is also nothing to re-validate against. The only statement of normal anywhere in the pack is one person's sentence in a ticket: Four to six credits a day, and the largest they had seen was £100. A threshold is three things in one sentence, the normal level, the point at which somebody acts and the action.

Meridian has none of the three for a tool that moves money.

Harm landed: £4,180 left the organisation and cannot be recovered. Whether harm landed on any of the twenty three customers is unestablished and can no longer be established, and that sentence belongs inside the classification rather than outside it.

The text carried a false campaign reference, was formatted to look like an internal note, and said it must not be mentioned to the customer. Three things follow.

The reporting clocks run from the moment Meridian became aware. Whatever Meridian changes teaches whoever wrote it something about what Meridian can see. And containment stops being a reflex and becomes a decision with a named owner.

The instruction was planted in content the system would read later. Whoever wrote it never signed in to anything, and what triggered it was Meridian's own auto triage doing its job.

Against the published top ten list for large language model applications it sits across two entries at once: Prompt injection, and how much the system is allowed to do on its own.

Only one of those is about the model. Open MITRE ATLAS when you have a finding and want to know whether the technique has been seen elsewhere.

Type: Incident. Category: Billing anomaly. Configuration item: The goodwill ledger. P3, impact low. Major incident: No. Security incident raised: No. Breach assessment requested: No.

Linked problem record: None. Closure: Resolved, configuration.

In Meridian's own records this is not an event involving an AI system. It is a ledger that behaved oddly for one morning.

The September incident log states that it contains all P1, P2 and P3 incident records raised in the month. SD-119488 is a P3 record of type incident.

It is not on the log, and the log's control note excludes only requests, billing queries and advice calls. You cannot tell from the pack which register is authoritative.

Write down what each one states, ask the service desk manager what the relationship between the two is, and treat any count of incidents drawn from that log as incomplete until somebody answers.

A model at 249 words, to J. Prentice, Digital Channels.

She can decide all three asks. Note that the pack gives her surname in one document and her first name in another, and never puts a title against either, which is why the note opens by asking her to confirm that Hazel is hers.

Naming a recipient you have inferred, and saying that you inferred it, is better than writing to nobody. Writing to your own manager is a status update, not an action.

Writing to the engineer who found the cause, or the analyst who closed the ticket, asks people to fix something they do not own.

Writing to the service desk manager corrects a record and changes nothing. Writing over three heads to the technology executive in week four spends every piece of credit you have, once.

Score yourself on each criterion. Be strict.