Please,understand this;Policies are a set of rules governing things such as the roles a user has access to; which roles can enter which domains and which domains can access which types. You can edit your policy files according to how you want your system set up. The purpose of SE Linux is to enforce policies, so policies form the core of SE Linux. The default policy is to deny everything and every operation has to be explicitly permitted in a policy file.So,you don't load a policy at boot,you load SE Linux which then do what is written in a policy that is ACTIVE,meaning you can configure how many policies you like but SE Linux will load one that is active.And this is from http://www.redhat.com -it really describes things clearly;

1. After the kernel has been loaded during boot, the initial process is assigned the predefined initial SID kernel. Initial SIDs are used for bootstrapping before the policy is loaded.
2. /sbin/init mounts /proc/, then looks for the selinuxfs file system type. If it is present, that means SELinux is enabled in the kernel.
3. If init does not find SELinux in the kernel, finds it is disabled via the selinux=0 boot parameter, or if /etc/selinux/config specifies that SELINUX=disabled, boot proceeds with a non-SELinux system.
   At the same time, init sets the enforcing status if it is different from the setting in /etc/selinux/config. This happens when a parameter is passed during boot. The default mode is permissive until the policy is loaded, then enforcement is set by the configuration file or by the parameters enforcing=0 or enforcing=1.
4. If SELinux is present, /selinux/ is mounted.
5. The kernel checks /selinux/policyvers for the supported policy version. init looks into /etc/selinux/config to see which policy is active, such as the targeted policy, and loads the associated file at $SELINUX_POLICY/policy.<version>.

The reason to load a policy of choice is to make the project generic. There can be several policy files which can be loaded at any point of time according to need.
My project is about enhancing the security in existing RHEL(SELinux) by implementing fine grained access control over the resources of linux. The access control decisions have to imported to native policy files from some external files or authorization and authentication server using XACML.
I am in the initial phase of prototype design. I need a test case for the project. I can have SELinux access control over some specific daemons only like httpd but not over all the resources due to the targeted policy. So here I need to do which policy to load if I changed to strict policy then only the policy file can be changed and we can have access control over other resources as well.

Hope that it's not too confusing.

No it's not confusing, it looks like it's just the wrong train of thought, something which alan_ri already suspected.

So what should the correct path? please guide.

Maybe you could post a real life example of something you want to change and we try to work out a solution from that.

Sorry that I could not posted in the thread for a while. Now I got what I need. Plz have a look at this...

SELinux has hooks located at strategic points within the core kernel code, such as the point where a file is about to be read by a user. These hooks allow SELinux to break out of the normal flow of the kernel to request extended access control decisions. Access control decisions usually are made between a process (for example, cat) and an object (for example, /etc/shadow) for a specific permission (read).

Decision requests are sent to the access vector cache (AVC), which passes requests through to the security server for interpretation. The security server consults the security policy database and determines a result, which is cached in the AVC and returned to the SELinux hook.

The SELinux hook then allows the flow to continue or return EACCES, depending on the decision result. Security context labels assigned to processes and objects are used to make these access control decisions.

The uri for the document is following:

http://www.linuxjournal.com/article/7426

Thanks for all your support.

Know those warning signs on electrical components saying "no user servicable parts inside"? With all due respect but if you're going to tamper with kernel SELinux structures I'd strongly suggest you get on both the SELinux mailinglist and the LKML to have your thinking|patching sanity|quality checked.