How write-once memory codes encode rewrites with monotonic cells

A storage cell that can change only from zero to one seems unsuitable for rewriting arbitrary data. After setting a bit, the encoder cannot clear it without an erase. Yet a logical message can have more than one physical representation. By choosing a representation reachable from the current state, an encoder can change the decoded message while every physical change still follows the permitted direction.

write-once memory codes use that freedom to support several logical writes between resets. Their contract concerns reachable physical states and the messages those states represent. It does not make the cells ordinarily rewritable, and it does not promise an unlimited sequence. The encoder eventually reaches a state from which some requested message has no reachable representation.

Define monotonic storage transitions before choosing a code

Consider three hypothetical binary cells, written as a three-bit vector. An erase initializes them to 000. During programming, any zero may stay zero or change to one; a one must remain one. A new vector y is reachable from current vector x exactly when every one in x is also one in y. Each programming operation may change more than one cell in this simplified model.

For example, 100 can become 101, 110, or 111, and it can remain 100. It cannot become 010 because that would clear the first cell. The vector 111 can only remain 111 until an erase. The state space contains eight vectors, but the encoder's current position determines which of them remain usable. A pending rewrite must be evaluated from the current vector.

The logical message has two bits and four possible values: 00, 01, 10, and 11. Assign physical states as follows: 000 and 111 decode to 00; 100 and 011 decode to 01; 010 and 101 decode to 10; 001 and 110 decode to 11. Every physical vector has one decoded message, and each message has two alternative representations.

This is a fully specified example of monotonic storage transitions with a fixed decoder. The decoder does not need to know which write number produced the vector. The encoder does need the current vector because it must select a representation reachable from that vector. Merely knowing the current decoded message can lose information: 000 and 111 both mean 00 but have very different remaining choices.

The moving-collection guide gives a representation-contract comparison for monotonic storage transitions. An object can move from address 1000 to 2000 while repaired references preserve its logical identity. That example separates what a representation means from its current physical form. Here several cell vectors represent one message, but the permitted next vector also depends on the current state. The collector guide supplies no monotonic codebook or rewrite guarantee; those follow from the specified cells and decoder below.

Trace multiple-write encoding from the erased state

For the first write, encode 00 as 000, 01 as 100, 10 as 010, and 11 as 001. All four choices are reachable from the erased state. Three messages set exactly one cell, while 00 leaves all cells unset. The decoder reads the intended two-bit message in each case.

Suppose the first message is 01. The physical state becomes 100. The next requested message is 10. Its representations are 010 and 101. The first is unreachable because it clears the first cell; the second is reachable because it preserves that cell and sets the third. Choose 101, and the decoder now reads 10. The logical value changed even though no physical one became zero.

A later request for 00 can use 111. From 101, setting the middle cell produces 111, whose decoded message is 00. This particular sequence supports three successful message writes: 01, then 10, then 00. Its success does not establish a guarantee of three arbitrary writes. A different sequence can consume the available transitions earlier.

To verify two arbitrary writes, examine all first-write states. From 100, a second 01 keeps 100, a second 10 uses 101, a second 11 uses 110, and a second 00 uses 111. From 010, the corresponding choices are 00 to 111, 01 to 011, 10 to 010, and 11 to 110. From 001, choose 111, 011, 101, or 001 for messages 00, 01, 10, or 11 respectively.

If the first message was 00 and the state remains 000, every first-write representation is still reachable for the second request. These cases cover all sixteen ordered pairs of messages. Each selected second vector satisfies the monotonic rule and decodes to the requested message. That is the stated guarantee: any pair of two-bit messages can be written from an erased three-cell block.

Show exhaustion despite unused representations

Choose first message 01 and second message 00. The physical sequence is 000 to 100 to 111. Now request 10. The two representations for 10 are 010 and 101. Neither is reachable from 111 because both require clearing at least one cell. Those states still exist in the codebook; they are unavailable from the present state.

Exhaustion is a reachability failure, not evidence that the stored message is corrupt. The decoder still reads 00 correctly from 111. The encoder simply cannot satisfy the new request under the current no-erase rule. It must erase and restart, move the data to another suitably prepared region under a broader storage protocol, or reject the request.

Repeatedly requesting the current message can often use a no-change encoding. At 111, repeated 00 requests remain decodable, but a request for another value fails. A count of repeated 00 requests omits the requirement that the next message may differ. A useful write-count claim specifies the allowed message sequences and whether repeated values count as writes.

Compare density and erase frequency under stated requirements

The code stores a current two-bit logical message in three binary cells, giving a current-message density of two-thirds of a bit per cell. It supports two arbitrary writes before an erase is needed for another unrestricted two-write cycle. Across those guaranteed writes, four logical payload bits have been accepted using the three cells, although the final state does not preserve both historical messages.

The cumulative four-over-three figure counts payload accepted over time. The final vector reveals the current two-bit message, without retaining both independent historical messages. An application that needs those two messages available afterward has a different storage contract, which this small code does not meet.

Compare a stipulated baseline that stores one arbitrary two-bit message per prepared block and erases before beginning each new write cycle. The rewrite code can accept two messages in its cycle, so under that baseline it reduces reset frequency per accepted message. It is not an estimate of host-write amplification, actual erase counts in a commercial drive, or the timing of a flash program operation.

The physical cost includes one additional cell per current two-bit message and an encoder that inspects the current state. Larger codes need their own density and guaranteed-write proofs. A chosen representation can leave more or fewer future options, so the proof must cover every admitted request from every relevant current state. The three-success sequence alone leaves that obligation unresolved.

The copy-on-write guide offers a separate-account comparison for multiple-write encoding. Its logical mapped payload can stay unchanged while additional private frames increase unique physical storage. The quantities need their own boundaries. Here current-message density and cumulative accepted payload likewise describe different accounts; the final vector preserves only the current message. Rewrite coding also differs from wear leveling: coding changes updates accepted before reset, while wear leveling distributes erase work across blocks. The page-copying guide establishes neither mechanism for an SSD.

Separate transition coding from error correction

The decoder above accepts every three-bit vector as some message. If the device incorrectly stores 101 when the encoder intended 100, the result decodes as 10 instead of 01. Nothing in this codebook flags that error. Multiple representations are being used to permit rewrites; their existence does not automatically provide error detection or correction.

If physical transitions can fail, the design needs an additional contract describing allowed errors and how success is checked. Readback can discover some differences between the requested and observed state. Recovery then has to consider the observed state, not the state the encoder hoped to create. A later attempt cannot safely assume an unconfirmed cell transition occurred or that an unwanted one can be cleared.

Error-correcting redundancy, transition-failure detection, and an atomic publication rule for the logical update may add storage and protocol requirements. Their guarantees must be evaluated together with monotonic reachability. An error can consume a transition and reduce the remaining write opportunities even if another layer recovers the current logical data.

An interrupted programming operation raises a related boundary. The simplified code assumes one chosen state is successfully established before the next logical request. If a real system can expose intermediate vectors, it needs a rule for recognizing a committed message and distinguishing incomplete writes. The small two-write proof alone supplies neither that publication rule nor a power-loss guarantee.

Audit the codebook and exhaustion cases

For the codebook audit, the Lenovo IdeaPad 15.6-inch FHD touch laptop can display all sixteen request pairs beside their reachable-state tests. Storage for the saved encoding worksheet is listed as a 512GB PCIe SSD; the entry also identifies 16GB DDR4 and an i5-1334U processor. Each row should name the first message, its selected vector, the requested second message and the reachable second vector. The worksheet verifies the declared code, while the catalogue supplies no evidence that the installed controller implements it or exposes monotonic cells to applications.

Keep successful decoding separate from request admission in an exhaustion table on the ASUS Vivobook 14 FHD laptop. Its memory specification is 16GB DDR4, and the native processor description names Core 5 120U. For state 111, record current message 00 as validly decoded, repeated 00 as a permitted no-change request, and new 10 as unreachable. No catalogue claim supplies those results or a measured endurance improvement.