Observe first. Change things when you are ready.
Most governance projects fail at the start, because step one is usually "change everything". Shastra is designed so understanding comes before enforcement.
Four stages, and you choose how far you go.
Sequence: Observe, then Govern, then Enforce, then Prove.
Three of six layers are optional.
Diagram: a user talks to the Compliance Copilot, which operates Shastra. Shastra contains a governance engine and an integration layer, with three optional layers: a proxy layer, an enforcement layer and an evidence layer.
Place Shastra in the path, if you want it there.
The simplest way to describe the proxy layer: you put Shastra between your application and the operations you want governed. Instead of observing from the side, it sits in the flow.
More detail
That gives stronger guarantees, because a governed operation passes through something that knows the policy. It also asks more of your architecture, which is exactly why it is optional.
Plenty of organisations will never need it. Integration flexibility is deliberate: being able to start without re-plumbing your systems is the difference between a governance project that begins and one that stalls.
Opt-in, and scoped by you.
Enforcement means Shastra actively acting on operations you have configured, rather than only recording what happened. It is off unless you turn it on, and scoped to what you choose.
More detail
We are deliberately not publishing claims about precisely which operations can be blocked or modified. That depends on your architecture and integration mode, and a generic promise here would be a promise we could not keep for every case.
Shastra is pre-launch.
Pre-registration is open, and no pricing is published while the product is still being built.
Related: the DPDP Act explained · the Compliance Copilot