You can view the formatted control(8) man page here:
http://docs.altlinux.org/manpages/control.8.html
(ALT Linux have imported owl-control for their distributions, and they have contributed some changes back to us. They also happen to have placed this man page on the web.)
I'm afraid that this is not going to help you very much, though, because owl-control is very generic and abstract, and so is its man page. Perhaps we should add a few usage examples to illustrate owl-control's purpose.
I'll try to explain what it's for. Some packages on Owl provide what we call, in owl-control terms, "facilities". An example of such facility is su, provided by the SimplePAMApps package. The package also provides the file /etc/control.d/facilities/su, which defines several possible settings for su. In this case, the settings are: public, wheel, wheelonly, restricted - as shown by "control su list". The default for su on Owl 3.0 is restricted, which corresponds to /bin/su being mode 700 (usable by root only). If you issue "control su wheelonly", /bin/su changes to mode 4710, with group wheel. Issuing "control su" then confirms that the current setting is indeed wheelonly. Other related programs are control-dump and control-restore: these are used by scriptlets of our RPM packages. For example, our SimplePAMApps.spec invokes "control-dump su" in %pre and "control-restore su" in %post. This lets a possibly customized control setting for su persist over upgrades of the SimplePAMApps package.
Some other facilities are: bind-debug (controls whether it's possible to have BIND produce debugging logs or not), ntpd (can be set to "server" or "client"), postfix (can be set to "server" or "local"), and many others. So this is not limited to changing permissions on files - it also works for configuration file contents - but we only use it for trivial changes (a line commented-out or not) that need to persist over system upgrades. Also, such control'able changes are perfectly compatible with manual edits to the corresponding config files. If a sysadmin ends up editing a file such that control's facility script does not recognize one of the supported settings, control will start reporting "unknown" for that facility's state - but that is not any worse than not having control would have been.
As you can see, this is a very nice security-relevant feature for sysadmins, but it is not central to the Owl security model. Things such as our tcb suite (making the passwd command run without requiring root privs) are more essential to our security model.