Engineering Principles
The rules and constraints that guide how I choose, structure, and implement software systems.
These are not abstract values. They are practical, recurring systems design decisions — why I prefer AST matches over semantic models for security, why I publish papers, and why documentation is treated as code.
Deterministic systems over probabilistic behavior
Most modern software systems choose probabilistic shortcuts because they are easier to build. A safety classifier is easier to deploy than a verified enforcement boundary. I accept this tradeoff in experiments, but not in core infrastructure.
When evaluating a choice between a probabilistic solution and a deterministic one, I ask: if this fails, will I be able to explain exactly why? If the answer is no — if the failure is just model drift or parameter variance — the solution is too fragile for runtime controls.
This is why Anchor evaluates policies using AST queries rather than LLM classifiers. Every execution query, policy ruleset, and context input must yield the same decision receipt, every time.
Governance infrastructure over AI applications
As large language models grew common, most engineering energy went into downstream products (wrappers, application bots). I was more interested in the control plane: how do you audit these systems? How do you authorize actions? How do you update policies without breaking prior compliance guarantees?
These are systems problems that cannot be solved by simply fine-tuning a model or adding a prompt safeguard. They require strict, verifiable infrastructure layers.
I focus on AI safety and governance tooling because application surfaces change rapidly, but the need for auditable, predictable execution boundaries is durable.
Research published alongside code
Systems engineering is incomplete without formal explanation. Writing research forces a precision that standard codebase development does not require. When design choices are written down, they can be scrutinized and improved by the community.
I maintain a first-principles research practice alongside my repositories. This includes submitting comments to central banks (RBI) and regulatory reviews (FSB) to verify that my academic assertions hold up under policy scrutiny.
Open-source code proves a system works; research papers explain why it is necessary. Both are essential.
Documentation as code
A software system without documentation is invisible. I treat architecture drawings, design logs, and sync specs with the same status as source code. They are maintained under version control, they decay without care, and they accumulate value when reviewed regularly.
This is particularly important for audit engines. If the rules of the system itself are illegible, the trust promises it makes to external compliance teams are broken.
Documentation must be self-describing, version-locked, and verifiable alongside the implementation.