The problem
A parity bit makes the total number of 1s in a transmitted value predictable, so a receiver can catch certain transmission errors. For even parity across 3 data bits (A, B, C), the parity bit P needs to equal 1 whenever an odd number of A, B, C are 1 — making the total count (including P) come out even:
| A | B | C | P |
|---|---|---|---|
| 0 | 0 | 0 | 0 |
| 0 | 0 | 1 | 1 |
| 0 | 1 | 0 | 1 |
| 0 | 1 | 1 | 0 |
| 1 | 0 | 0 | 1 |
| 1 | 0 | 1 | 0 |
| 1 | 1 | 0 | 0 |
| 1 | 1 | 1 | 1 |
That's P = A ⊕ B ⊕ C — three-input XOR.
What happens when you try to group it
Plot those four 1s (minterms 1, 2, 4, 7) on a K-map and look for adjacent cells. There aren't any — each of the four 1s is surrounded entirely by 0s. Verified against the actual solver: every single prime implicant covers exactly one minterm, and all four are essential:
Four terms, three literals each — twelve literals total, for a function of only three variables. That's not a failure to find a better grouping; there genuinely isn't one. This is the defining property of parity/XOR-structured functions: the 1s and 0s alternate in a checkerboard pattern where no two required cells are ever adjacent, which is exactly the property a K-map's grouping rule depends on to do anything useful at all.
Why this matters practically
In real circuit design, parity and other XOR-heavy functions are built directly from XOR gates rather than run through K-map minimization at all — trying to simplify them with AND-OR logic the normal way produces exactly the twelve-literal result above, which is correct but not remotely efficient. Recognizing an XOR-shaped truth table on sight — alternating 1s and 0s with no adjacency — is worth as much as knowing how to group: it tells you K-map simplification is the wrong tool for this particular function, and a direct XOR (or XNOR) implementation is what you actually want.