Lesson 1 of 6 · One neuron

How does a model turn a ticket into a prediction?

Suppose you want to flag support tickets for a security review. We’ll build a small example: two inputs, a few stored numbers, and a calculation you can follow by hand.

Step 1 · Represent a ticket

Training data contains examples and answers

A feature is a number the model receives about one example. A label is the answer we want it to learn during training. At prediction time the label is hidden—the model must produce a prediction.

Our example represents a ticket with two yes/no features. x₁=1 means the ticket mentions credentials. x₂=1 means it describes an unauthorized action. A reviewed ticket’s label y=1 means it belonged in the security queue.

Concrete example

One ticket becomes one training row

  • Ticket“A pasted API key allowed an unauthorized deploy.”
  • x = [1, 1]Credentials present; unauthorized action present.
  • y = 1A human reviewer says this belongs in security.

Quick check

Which value is the label?

Step 2 · Compute a score

Weights say how much each feature matters

The feature values change for every request. The weights and bias are parameters stored in the model. Training changes parameters; a normal prediction does not.

A neuron multiplies each feature by its weight, adds those contributions, then adds a bias. The result z is a logit: a raw score, not yet a probability.

Worked calculation

Credentials present; unauthorized action absent

z = x₁w₁ + x₂w₂ + b

z = (1 × 1.2) + (0 × 0.7) − 0.5 = 0.7

The second weight is still part of the model, but this ticket’s zero-valued second feature contributes nothing to this score.

Predict before touching the controls

If x₂=0, what happens when w₂ changes from 0.7 to 3.0?

Step 3 · Separate model from policy

Sigmoid changes the scale; the threshold chooses the action

The sigmoid function maps any logit to a number between zero and one. For z=0.7, sigmoid produces about p=0.668.

Here, p estimates the probability that the reviewed label is security. It is not the probability that the application will route the ticket. The application compares p with a threshold: 0.668 passes 0.50 but fails 0.80. Sigmoid puts the output on a probability scale; it does not prove that the estimate is accurate.

One output, two policies

  • Modelsigmoid(0.7) = 0.668 in both deployments.
  • Policy A0.668 ≥ 0.50 → route to security.
  • Policy B0.668 < 0.80 → use ordinary routing.

Practical example · Forward-pass workbench

Change the request, model, and policy separately

First set x₂=0 and move w₂; confirm the probability stays fixed. Then leave every model value fixed and move only the product threshold.

Routing decision

estimated probability that the ticket belongs in security

Python bridge · the entire forward pass
z = x @ weights + bias
probability = 1 / (1 + np.exp(-z))
route_to_security = probability >= threshold

The first two lines are model computation. The third line is application policy. Open the complete deterministic example when you want the full loss and update.

Your turn

Explain it in your own words.

Not checked

A ticket gets a security probability of 0.68. Compare changing the ticket's feature values with changing only the routing threshold from 0.50 to 0.80. Which change can alter the model's probability, and why can the threshold change routing while leaving 0.68 alone?

Answer the question in your own words. A short explanation is enough.

Draft saves on this device0/800 characters

Work through a hint