A trap state, also known as a dead or sink state, is a non-accepting state that, once entered, cannot lead to an accepting state. It is used when an input string has permanently violated the condition required for acceptance. For example, in a FSM designed to accept strings of exactly three symbols, any input beyond three characters should transition to a trap state. All transitions from the trap state simply return to itself regardless of the input symbol. This prevents the FSM from accidentally accepting invalid strings later in processing. Trap states help simplify the design by handling invalid inputs in a single location rather than complicating other states with error logic. They’re particularly useful in exam conditions for clarity and ensuring deterministic behaviour. A well-placed trap state makes the FSM easier to read and guarantees that all invalid paths are managed predictably and cleanly.

FSMs have no memory other than their current state. They do not have variables, stacks, or tapes to store values like a Turing Machine or a Pushdown Automaton. Because of this, they can only "remember" a finite number of conditions, each represented by a unique state. So, if you wanted an FSM to accept strings with exactly ten 1s, you would need to design an FSM with at least eleven distinct states (including a trap state) — one for each count from 0 to 10. But if you wanted to accept strings with any number of 1s — or to count them indefinitely — it would be impossible with a finite number of states. This limitation makes FSMs suitable only for problems with finite, bounded conditions. They are ideal for recognising patterns with clear limits or repeating structures, but not for problems requiring unbounded counting or recursive memory. That’s where more powerful models like Turing Machines are needed.

The number of states in an FSM depends entirely on the amount of memory required to track the relevant input history. You should start by analysing what the FSM needs to remember in order to accept or reject a string. For instance, if you need to identify a specific ending like ‘01’, then your FSM needs to track at least the last two symbols. This would require a minimum of three or four states to account for all possible combinations (e.g., none seen yet, seen 0, seen 1, seen 0 then 1). If you're designing for string length, each input symbol usually requires a new state to count correctly. Always look at the minimum amount of history the FSM must record using its states — but avoid adding redundant states. Each state should represent a distinct situation in the processing of the input. Diagramming possible inputs often helps clarify the minimum required structure.

Yes, FSMs can be designed to accept multiple patterns, but it requires careful planning and possibly more states. The FSM must be able to differentiate between the patterns based on the input and transition accordingly. For example, if you want a machine to accept binary strings that end in either ‘01’ or ‘10’, the FSM must be structured so it transitions into an accepting state upon reaching either sequence. This typically means creating states that represent the possibility of both endings and handling overlapping transitions. States will often need to remember partial progress towards both patterns. However, if the patterns are complex or interfere with each other, the FSM might require many states to resolve ambiguities. It's essential to ensure that all transitions are deterministic, and every input from every state leads to exactly one next state. Merging machines for different patterns can be done, but it often increases the FSM's complexity.

Accepting based on content means the FSM checks for specific sequences or patterns within the input symbols, such as ending in ‘01’, containing ‘101’, or having an even number of 1s. These designs focus on what is in the string. In contrast, accepting based on structure involves properties like string length or position of elements — for instance, strings of exactly three symbols, or strings where every third character is a ‘1’. Structural FSMs often rely on counting how many symbols have been read, requiring a chain of states corresponding to each position in the string. Content-based FSMs tend to loop and transition depending on symbol sequences, while structure-based FSMs are more linear or layered. In practice, FSMs may use a combination of both strategies, but recognising the distinction helps you decide how to structure your states. Content-based FSMs track what has been seen, and structure-based FSMs track how far in the input you are.