We are making a solution where a user is supposed to evaluate a number of requirements and laws. These evaluations all happen on one page, and the requirement/law is evaluated one at at time - all the information on the page is piled up and saved with a click on Save Changes, both per client request and by analogy with a previous system.
The law/requirement is shown to the left and the evaluation (how the law is followed, etc) is filled in on the right. Each have a few pieces of data, which for the evaluation means a few input fields.
However, while laws are predetermined, requirements can also be added by this same user, along with its evaluation, and the requirement can be edited. Leaving aside issues of data integrity (there will be an audit trail), we have a problem with the appearance of "nested edit states".
It is our client's inclination to show the requirement as non-editable text, similar to the way laws are presented, both for consistency and readability (not having to scroll in a text box). This invites adding an edit button to toggle edit mode just for the requirement box, and show input fields at that point. However, this comes with a bunch of undesirable consequences.
The rest of the page is already perpetually in edit mode, and being able to commit a certain part of it may mistakenly convey that any changes are immediately saved to the database (they aren't).
We have looked into inline edit/click to edit, but it seems to invite being able to do so for the laws, too, which you can't, and also asks the question why all of the forms on the rest of the page (the actual evaluation fields) are not designed in the same way. Additionally, it takes extra work to make tabbing work. Click to edit makes sense for single, seldom changed fields, but we are talking about three or four fields, and it would be pedagogical to show them all as editable at once.
The biggest problem is that it just seems off to have nested states with different lifetimes, where you can commit or discard some changes in a way that has no parallel in the rest of the page.
My best hunch right now is to hoist the edit requirement functionality into a modal, which although it may seem clunky, is at least more explicit about the nested states. But this seems like a bit of a frankenpattern in general. Is there a clearer solution that I am missing, or would things work out just fine if I just relaxed some part of this? The earlier system just had all fields editable at all time, which avoided this problem - is that still the best way to go?
Update: We've gotten great answers and the wide variety of the solutions has also told us something about the difficulty of picking one that feels reasonably natural to everyone. As it stands, our current thinking is:
If at all palatable, just break up the entering of new requirements into another page. Requirements and laws will still be visible on this page (since it is necessary to evaluate them), but editing or entering new ones will not be possible.
If not, we will push for making the requirements editable in situ, without a trigger, to avoid the extra state.
If not even that is workable, we will promote the editing of the requirement to a modal, with "update" and "discard" as the actions, to make the state clearly ephemeral.
Many people pointed out the ambiguity of what the Call To Action was, and how it makes the page more involved (and creates these sorts of questions). Some other people questioned the apparent influence of our client's inclination. The client is asking us to solve their problem for them and it is incumbent on us to find the right solution, so the natural order is for things to sometimes take a different situation. However, the situation and understanding is not always that pure and this site is filled with people who manage this tension daily.
I don't know where we'll end up but all answers have been very helpful. The first option wasn't proposed as an answer but is in a way the natural conclusion of demanding that the Call To Action be clear - give them separate pages, where they can be clear. Permissions will likely demand that only some people can enter requirements, so it would be completely necessary from this point.
The bounty and the accepted answer goes to Assimiz's answer, which was the first answer to propose our second option. For anyone who finds themselves in this sort of situation, I think the take-away is that while there are ways to solve this problem neatly, it is a sign of a cognitive burden, of being able to mess with things that you really shouldn't be able to mess with at that point in time.
Update 2: After some discussion, the client agreed to the first option above - to split the page into two pages, where one is to manage requirements and one is to evaluate laws and requirements.