1. How does it work?

Instead of writing a word/pdf/... document where the dev team describes what placeholder have to be replaced, the dev team provides a PACIFy configuration marker file:

deployment-package-app-v1.0
   |- config
   |   |- log4j.xml
   |   |- ...
   |- datasource
   |   |- config.xml
   |   |- ...
   |- web
   |   |- infopage.html 
   |   |- ...
   |- server
   |   |- app.ear
   |   |- ... 
   |- app-CMFile.pacify        <-- Configuration Marker File

which contains the information and is part of your package. This marker file looks like:

<Pacify>
    <File RelativePath="config/log4j.xml">
        <Property Name="log.level"/>
    </File>
    <File RelativePath="datasource/config.xml">
        <Property Name="jdbc.url"/>
    </File>            
    <File RelativePath="web/infopage.html">
        <Property Name="jdbc.url"/>
    </File>
    <Archive RelativePath="server/app.ear">
        <File RelativePath="META-INF/weblogic-application.xml">
            <Property Name="thread.count"/>
        </File>
    </Archive>
</Pacify>

and is based on a schema. You don't have to specify all configuration elements in one configuration marker file. You can create as many as you want on any location within the package.

For the ops team it's now really easy to configure that package for a specific environment. They provide the values for the environment and call PACIFy:

java -jar pacify.jar replace                                \
       --packagePath=/share/app/deployment-package-app-v1.0 \
       ...=prod.properties

If PACIFy successfully finished his work you can be sure that the package is now configured and nothing is missing! In this example, the op's team used a property file to resolve the properties, but PACIFy can handle more.