In order to abstract how a concrete model (such as FH:Model::DBIC) exposes its internal, raw view of its current data, add a new abstract method on FH:Model called 'item_values', which is expected to be a read only accessor that is a hash ref of field/values. Concrete types of this model should do something sane with this method.
This avoids any need for hard structural bindings between FH and a given type of model in the case where you want to access the model data, such as when after an insert the DBIC model will have autogenerated PKs, default values that are not otherwise default in the Form, or other types of generated data.
Current example use case for this : https://github.com/jjn1056/CatalystX-Example-Todo/blob/master/lib/CatalystX/Example/Todo/Web/Controller/API.pm#L27 which is a case where I want to return as JSON the database PK and a default column 'status', which the Form itself knows nothing about. In the linked case the only way to get this data is by reaching down into form->item and called a model specific method, which breaks encapsulation and unnecessarily exposes the controller to model specific details.
abstract how a model exposes its internal view of data to the form
I can see the issue here, but I don't think this is the way to solve it, since it introduces a third way to get at the values other than the existing two methods ($form->value & $form->item), and doesn't seem to be better from an encapsulation standpoint to me. I'm going to give this some more thought. We can discuss offline.