Using NVP as a model is a good start and good decision. But I see your problem. Take the following with a large grain of salt as I'm really just speculating without really thinking. instead of handling FIELD as a member function in your archive like xml archives to with NVP, consider the following: a) make a FIELD wrapper similar to make_nvp - I assume you've already got this. Note that you should set the new "is_wrapper" trait described in the latest version 1.35 checked in to the HEAD branch. This will permit the FIELD type to pass through the compile time traps which detect unwise behaviour. Alternatively, you can disable the compile time trap. See the last section in "Rationale" regarding the compile time trap. b) implement serialization for objects of FIELD type in more or less the normal way. Use NVP as a model. This will permit serialization of your FIELD with any archive. I don't know if you've done this yet c) Make your own archive .... but DON"T do what xml_archive does with NVP. That is, don't include an override for FIELD in the archive class itself. d) make your own specializations for the function template serialize. (Assuming non-intrusive serialization here), (Assuming compiler supports partial function template ordering correctly). template<class T> void serialize(tibco_oarchive & ar, field<T> &t, const unsigned int version){ ... // special stuff for "field" } and template<class T> void serialize(polymorphic_tibco_oarchive & ar, field<T> &t, const unsigned int version){ ... // special stuff for "field" } note that this code can be included in your header "field.hpp" so that is seen when and only when you're using FIELD. This will move the "extra specical sauce" for FIELDS on the tibco_oarchive to inline code BEFORE it even gets the polymorphic archive itself. There could be a problem with start/end though. "I'm building at my place of work as a more flexible replacement for Rogue Wave's "saveGuts/restoreGuts"." Wow - I wish I'd thought of THAT name. Robert Ramey