> ## Documentation Index
> Fetch the complete documentation index at: https://docs.merchantops.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Manual edits
> How a hand-edited property is marked, what protects it from feed imports, and how to release it.
When you change a product property yourself, MerchantOps records that the value
came from a person rather than a feed or a machine. That record is what stops the
next import from quietly putting the old value back. This page explains how the
mark is applied, what it protects against, what it doesn't, and how to remove it.
## What gets marked
When you change a product property, MerchantOps compares the new value against
the one it replaced. Every property whose value **actually changed** is marked as
a manual edit and stamped with:
* **who** made the edit, and
* **when** they made it.
Properties you didn't touch are left exactly as they were — saving a form without
changing a field never marks it. Existing marks carry forward when a new
[version](/catalog/versioning) is created, so provenance survives version bumps
and the protection doesn't expire after one import.
In the app, a marked property shows a **✋ Manual** badge next to it on the
product page; hover it to see who edited it and when.
This applies to edits made through the app and through the API alike — anything
that writes properties as a person rather than as an import.
## What the mark protects against
**Feed imports.** When an import brings in a product that already has manual
edits, MerchantOps keeps your value for every marked property, carries the mark
forward, and — where the incoming file actually disagreed with your edit —
records a **conflict** on the [import job](/jobs/overview). The conflict names the
property, the value the feed carried, and the value that was kept, so a dropped
feed value is never silent.
There is one deliberate exception. A JSON import can be run with **Overwrite
manually-edited fields** ticked, for an authoritative resync where the file is the
source of truth. That turns the protection off for that run. If you only want to
protect specific fields during a resync, leave them out of the file rather than
ticking the box.
## What the mark does not protect against
The manual-edit mark is read by the import path. **Enrichment does not read it.**
Enrichment has its own, separate guard: the per-property
`overwrite_merchant_input` switch, described in
[How enrichment works](/enrichment/how-it-works). Because a hand edit records the
value's source as your input, that guard is what covers it — and it is **off by
default**, meaning your value stays.
The exceptions are the three content fields that ship with overwriting **enabled**,
because they are copy MerchantOps is expected to author:
* **Description**
* **Features**
* **Meta title**
On those three, an enrichment run may replace text you typed, mark or no mark. If
you want a hand-written description to survive enrichment, turn
`overwrite_merchant_input` off on that property in the **Property Dictionary** —
see [Enrichment configuration and overrides](/catalog/product-types-properties)
for where the setting lives and how to scope it to one product type or category.
## Releasing a property back to the feed
When a hand edit has served its purpose — the source system has been corrected,
say — clear the mark with **Reset to feed** next to the property on the product
page. An API client can do the same by clearing the manual-edit flag in the
property's metadata.
Reset to feed removes the protection on the latest version. It does **not** change
the current value: the value you edited stays until a later import overwrites it.
Which source wins a field, and the overwrite guard that governs enrichment.
How editing creates a new version and which one to trust.
Where import conflicts are reported.
How scheduled feeds bring product data in.