Aptitude skill lesson
Diagrammatic reasoning: skill lesson
Diagrammatic reasoning is the ability to execute a diagram: to run an input through a chain of operator boxes, trace a flowchart with a real value, follow a state machine through a sequence of events, or read a dependency network and say what slips if a task runs late. It appears in technology and engineering screening, business-analyst and process-improvement selection, and any battery that uses transformation-box items. It is also, of the abstract constructs, the one closest to daily work: an approval flow, a deployment pipeline and a fault-finding decision tree are all diagrams somebody has to execute correctly. Practice is device-local and nothing leaves this device unless you export it.
Published · last reviewed
Applies to Novus Learn 0.1.0
What changed, and when
- , Replaced the body of all 27 non-judgement lessons with construct-specific material: six worked examples each, carrying the actual arithmetic, the actual inference or the actual procedure, plus expanded objectives, practice tips and glossary. Every 'Related Learn topics' link now points at a real page on this site rather than a generic search. The eight workplace-judgement lessons are unchanged.
- , Rebuilt the lesson page around a sticky contents rail, per-section links, previous/next lesson navigation, and two graded checkpoints drawn from the open practice bank.
- , Repaired the aptitude integrations behind the lessons so each one links to skill-specific practice instead of the unscoped fixture engine.
- , Published one lesson for each of the 35 aptitude skill constructs: objectives, worked examples, practice tips, glossary, Learn topic links, and sources.
These 35 skill lessons are authored and revised as one set, so they share one revision history rather than 35 identical dates.
Objectives
Copy link- Apply a chain of defined operators to an ordered input in the correct sequence, and explain why reordering the operators changes the output.
- Infer an unknown operator from input and output pairs, and identify when a single pair leaves several operators indistinguishable.
- Trace a flowchart containing a loop and a decision node with a specific starting value, recording the state after every pass.
- Read a process diagram with threshold decisions and resolve boundary cases correctly against the wording of each condition.
- Follow a state machine through an input sequence and report both the final state and the number of times a given transition fired.
- Compute the critical path of a small dependency network, work out the float on each other path, and predict the project impact of a specific delay.
Checkpoint: does the idea land?
Copy linkBefore the worked examples, check that the objectives above actually landed.
Two questions from the open practice bank, answered here and scored on this device. Untimed, ungraded, and not added to your practice history, the full bank is where attempts are recorded.
Examples
Copy linkRunning an operator chain, in order
Three operators act on an ordered list of four items. Triangle reverses the order of the whole list. Circle swaps the first two items. Square flips the colour of the last item between black and white. The input is: white circle, black square, white triangle, black star. Apply triangle, then circle, then square. After triangle the list is black star, white triangle, black square, white circle. After circle, which swaps the first two, it is white triangle, black star, black square, white circle. After square, which flips the last item, the white circle becomes a black circle, so the output is white triangle, black star, black square, black circle. Now change the order to square, then circle, then triangle. Square flips the last item of the ORIGINAL list, the black star, to a white star. Circle swaps the first two: black square, white circle, white triangle, white star. Triangle reverses: white star, white triangle, white circle, black square. Completely different, because square and triangle both act on positions and reversing the list changes which item is last. That is the whole lesson of operator items. The operators are not commutative, and a candidate who applies them in the order they find easiest will produce a legal-looking output that is wrong. Write the intermediate list after every box. The bookkeeping is the item.
Deducing an operator, and knowing when one example is not enough
You are shown two examples of an unlabelled operator. The list 1, 2, 3, 4 becomes 2, 1, 4, 3. The list A, B, C, D becomes B, A, D, C. The operator swaps items in adjacent pairs: positions one and two exchange, and positions three and four exchange. Test it on a third input, W, X, Y, Z, and it should give X, W, Z, Y. Now the honest caveat that these items are built on. Suppose you had only been shown a two-item example, 1, 2 becoming 2, 1. At least three different operators produce that: swap adjacent pairs, reverse the whole list, and rotate the list by one position. On a two-item list they are indistinguishable, and any answer you give is a guess dressed as a deduction. This is why transformation items normally supply at least two examples of each unknown operator, and why the productive move when you feel certain after one example is to ask what other operator would have produced the same result. Where a test does give you only one example, check the answer options: if two options are consistent with the example, the item is relying on some further constraint elsewhere in the diagram, and that constraint is where the answer lives.
Tracing a flowchart with a loop
A flowchart: START, read a whole number n, set a counter c to zero. Then the loop. Is n equal to 1? If yes, output c and STOP. If no, is n even? If yes, replace n with n divided by 2; if no, replace n with three times n plus one. Then add one to c and return to the top of the loop. Trace it with n equal to 6, writing the state after each pass: n is 6 and even so it becomes 3, c is 1. Three is odd so it becomes 10, c is 2. Ten becomes 5, c is 3. Five is odd so it becomes 16, c is 4. Sixteen becomes 8, c is 5. Eight becomes 4, c is 6. Four becomes 2, c is 7. Two becomes 1, c is 8. Now the top of the loop finds n equal to 1, and the output is 8. Three errors account for nearly all wrong answers here. Testing n even before testing n equal to 1 makes the loop run one pass too far. Incrementing c inside both branches as well as after them double-counts. And abandoning the trace once the value starts rising, six goes up to 10 and then to 16 before it comes down, leads people to assume they have made a mistake. Keep a two-column table of n and c, one row per pass, and the item becomes clerical rather than clever.
Threshold decisions, and the boundary that decides them
A purchase approval flow. A request arrives. First decision: is the amount 500 or less? If yes, the team lead approves and a purchase order is raised. If no, second decision: is the amount 5,000 or less? If yes, the department head approves, finance reviews, and a purchase order is raised. If no, a director approves, finance reviews, and a purchase order is raised. Now three requests. A request for 500.00 exactly takes the first yes branch, because the condition is 500 or less and 500 satisfies it: team lead only, no finance review. A request for 500.01 fails the first decision and passes the second: department head plus finance review. A request for 5,000.00 exactly passes the second decision, so it is also department head plus finance review: not the director. That last one is the item most candidates lose, because 5,000 reads as the top of the range and feels like it should trigger the higher tier. Read the operator, not the number. Or less, up to, and not exceeding include the boundary; under, below and more than exclude it. When a diagram uses a bare inequality symbol the same discipline applies, and if the diagram genuinely does not say, that ambiguity is itself the answer to a well-written question about process risk.
A state machine, and why two coins buy one pass
A turnstile has two states, Locked and Unlocked, and accepts two inputs, coin and push. From Locked, a coin moves it to Unlocked and a push leaves it Locked. From Unlocked, a push moves it to Locked and lets one person through, while a coin leaves it Unlocked. Start in Locked and run the input sequence push, coin, coin, push, push, coin. Step through it. Push in Locked: still Locked, nobody through. Coin: Unlocked. Coin again: still Unlocked: the second coin buys nothing, because the state was already Unlocked and the transition from Unlocked on a coin loops back to Unlocked. Push: Locked, one person through. Push again: still Locked, nobody through. Coin: Unlocked. Final state is Unlocked, and exactly one person passed. The two questions a state-machine item asks are the final state and the count of some transition, and the second is where the marks go. Candidates count coins and answer two, because in the real world two coins ought to buy two entries; the diagram says otherwise, and the diagram is the authority. The general habit is to write the state after every single input in a single row, including the inputs that change nothing, since a transition that loops back to the same state is exactly the one a rushed trace silently drops.
Critical path, float, and which delay actually costs you
A small project. Task A takes 3 days and starts immediately. Task B takes 4 days and follows A. Task C takes 2 days and also follows A. Task D takes 5 days and follows B. Task E takes 6 days and follows C. Task F takes 1 day and cannot start until both D and E are finished. Two routes run from start to finish. A, B, D, F totals 3 plus 4 plus 5 plus 1, which is 13 days. A, C, E, F totals 3 plus 2 plus 6 plus 1, which is 12 days. The project takes 13 days and the critical path is A, B, D, F. The other route has one day of float: it can absorb a single day of delay without moving the finish date, because F still has to wait for D. Now the question these items are built around. Task E slips by two days. Does the project slip? The C-E route becomes 3 plus 2 plus 8 plus 1, which is 14 days, and 14 is greater than 13, so the project finishes one day late. The first day of slip was absorbed by the float and the second was not. The trap answers are no delay, from assuming that a non-critical task is free, and two days, from assuming the delay passes straight through. Float is the buffer, and only the delay beyond it reaches the finish date. Note too that the critical path has now moved to A, C, E, F, which is why the path must be recomputed after any change rather than assumed to be fixed.
Checkpoint: can you apply it?
Copy linkNow apply it. These come from a later section of the bank, so they are not more of the same.
Two questions from the open practice bank, answered here and scored on this device. Untimed, ungraded, and not added to your practice history, the full bank is where attempts are recorded.
Practice tips
Copy link- Write the intermediate result after every operator box. Diagrammatic items are lost to bookkeeping far more often than to misunderstanding, and an unwritten intermediate state is an unverifiable one.
- Never assume operators commute. If the diagram routes an input through boxes in a particular order, apply them in that order even when a different order looks tidier, because position-based operators interact.
- Trace loops in a two-column table, one row per pass, with the loop variable and the counter side by side. Then check the exit condition is tested where the diagram tests it, not where it feels natural.
- Circle every threshold word in a decision diamond and decide explicitly whether the boundary value is inside or outside before you evaluate any case. Or less and under are different diagrams.
- On state machines, record the state after every input including the ones that change nothing. Self-loops are the transitions rushed traces drop, and they are usually what the counting question is about.
- Recompute the critical path after applying any delay rather than assuming it stays where it was. Attempts are recorded on this device only, so run a network twice with different delays and watch the path move.
Glossary
Copy link- Operator box
- A labelled transformation applied to an input as it passes through a diagram. Operators are generally non-commutative, so the routing order changes the output.
- Decision node
- A diamond in a flowchart carrying a condition with two or more labelled exits. The wording of the condition decides which branch a boundary value takes.
- Loop
- A path in a flowchart that returns to an earlier node. Correct tracing depends on where the exit condition is tested relative to where the variables are updated.
- State machine
- A diagram of states and labelled transitions between them. The current state plus the next input fully determine what happens, and nothing else in the item does.
- Self-loop
- A transition that returns a state to itself, such as inserting a coin into an already unlocked turnstile. It consumes the input but changes nothing, and it is the most commonly dropped step in a trace.
- Critical path
- The longest chain of dependent tasks through a network. Its length is the shortest possible project duration, and any delay on it delays the whole project.
- Float (slack)
- The amount by which a non-critical task can slip before it affects the finish date. Delay beyond the float passes through to the project, and consuming the float can move the critical path.
- Swimlane
- A horizontal or vertical band in a process diagram assigning each step to a role or team. Handoffs between lanes are where process items usually locate the question.
Sources
Copy link- Every operator chain, flowchart trace, state sequence and network above was constructed and executed by hand for Novus Learn. The loop example follows the Collatz rule, a standard public teaching example, and the trace from n equal to 6 was checked step by step.
- Terminology checked against the public Wikipedia articles 'Flowchart', 'Finite-state machine', 'Critical path method' and 'Float (project management)'. Definitions only; all diagrams described are original.
- Novus Learn aptitude construct registry (catalog seed) for the construct scope and related suite mapping.
- Public educational framing only: not affiliated with any official exam board, publisher or employer, and no copyrighted test item is reproduced.
Your notebook for this lesson
Saved sections and notes are kept in this browser, on this device. No account is required, and nothing is sent to us unless you create one and switch on backup. They travel with your backup file from My Learning, and they are lost if you clear this site’s data.
Saved sections
None yet. Use Save beside any section heading above to keep it here.
4000 characters left
Your own words, so you can find this again from any other lesson. Up to 12.