If a state transition table is missing transitions for certain state-input combinations, it means the FSM is not total. In deterministic FSMs used at A-Level, it is generally expected that the machine has a defined transition for every possible input from every state. If a transition is missing, the machine will have undefined behaviour for that input, which usually means it will reject any string that encounters such an input in that state. To resolve this, you should either explicitly define what the next state is (even if it transitions to a “trap” or “dead” state that rejects all subsequent inputs), or revise the FSM’s design to ensure complete coverage. In exam conditions, if asked to complete or correct such a table, your goal should be to fill in the missing transitions by logically extending the machine’s intended behaviour, maintaining determinism and correctness. Unfilled transitions can also indicate non-deterministic behaviour, which is outside the AQA FSM scope.

Yes, a finite state machine can have multiple accepting states, and this is a common design pattern used to allow strings to be accepted under a variety of end conditions. In a state transition table, accepting states are not marked directly within the table’s rows. Instead, they are listed separately as part of the FSM’s definition. When using the table to simulate the machine, once the input string has been fully processed, you check whether the final state reached is in the list of accepting states. If it is, the string is accepted. If not, it is rejected. The transition table itself remains the same structure regardless of how many accepting states exist. For clarity, when creating or interpreting FSMs with multiple accepting states, it is helpful to explicitly note the full set of accepting states near the table or in accompanying annotations, especially when checking multiple inputs against the FSM.

When designing a state transition table for an FSM with more than two input symbols, such as one with an alphabet like {a, b, c}, the best approach is to systematically expand the table to ensure full coverage of all state-input combinations. First, list all states vertically and all input symbols horizontally (or vice versa, depending on layout). Then for every pair (state, input), specify the next state explicitly. This ensures that no transition is overlooked, which is particularly important in FSMs with a large input alphabet. If drawing this out in exam conditions, a row-per-transition format (current state, input symbol, next state) is preferred. For clarity, avoid duplication and aim for consistent naming conventions. If any input is irrelevant to a certain state (i.e. the state does not respond to it), you can still include the transition, usually leading back to the same state or to a reject state. Consistency and completeness are essential in avoiding ambiguous FSM behaviour.

To determine if a state transition table represents a looping or cyclical FSM, examine the pattern of transitions between states. If there are paths where the FSM returns to an earlier state after a series of inputs, it is considered to have a cycle or loop. For example, if state A transitions to B on input 1, and B transitions back to A on input 0, this creates a loop: A → B → A. Also, any state that transitions back to itself under one or more inputs is a self-loop, which is also a form of cyclic behaviour. You can trace cycles by starting at each state and simulating input sequences to see if the machine revisits the same state more than once. FSMs with cycles are common in pattern recognition problems, especially those that must process repeated or varying sequences. Loops are valid and intentional, but they must still lead to an accepting state when the string is valid.

Yes, and in fact, it is expected to have multiple rows with the same current state in a state transition table — one for each different input symbol. Since a deterministic FSM defines exactly one transition for every (state, input) pair, a state like A would appear in multiple rows: one where A receives input 0 and another where it receives input 1 (and more, if the input alphabet includes additional symbols). Each of these rows would map to potentially different next states. This structure ensures clarity and consistency in how the FSM behaves for different inputs. Importantly, no row should repeat the same (state, input) combination with different results — doing so would imply non-determinism, which is not allowed in the AQA FSM specification. Therefore, the presence of multiple rows with the same current state simply reflects the FSM's complete definition across its input alphabet, not duplication or error.