diff --git a/docs/.nojekyll b/docs/.nojekyll
new file mode 100644
index 0000000..e69de29
diff --git a/docs/index.html b/docs/index.html
new file mode 100644
index 0000000..e9ca129
--- /dev/null
+++ b/docs/index.html
@@ -0,0 +1,202 @@
+
+
+
+
+
+
+Tirith — IaC Governance plugin
+
+
+
+
+
+
+
+ Tirith — IaC Governance plugin
+
+ Plugin IaC Governance for any pipeline, running anywhere. Evaluate plans with Tirith, protect
+ sensitive values, enforce centralised governance, and surface actionable results before
+ infrastructure changes are applied.
+
+
+ Tirith reads the plan your pipeline already produces, checks it against your policies, and exits
+ non-zero so a violating change never reaches apply. Apache-2.0, and no account
+ needed.
+
+pip install git+https://github.com/StackGuardian/tirith.git
+
+ Repository
+ Documentation
+
+
+
+
+
+ The problem
+
+ A pipeline that runs init, plan and apply deploys whatever
+ the plan says. Nothing sits between the plan and the change.
+
+
+ - Every repository does it its own way, so there is no one place to see what was deployed, or what was refused.
+ - Rules that do exist live in whichever pipeline someone wrote them into, and get copied into the next repository by hand.
+ - When a check does fail, the log says a job failed. It does not say which rule, on which resource, or what value broke it.
+
+
+
+
+
+ What you add
+ Two lines, on GitHub Actions:
+- run: terraform show -json tfplan > plan.json
+- uses: StackGuardian/tirith-iac-governance-action@v2
+
+ With a plan.json in the working directory that is the whole integration — no
+ with: block. Policies are JSON files committed under
+ .tirith/policies.
+
+
+
+
+
+ What you get
+
+ -
+ Policies as data, not code. A rule is a JSON file describing what to look for,
+ rather than a program you have to maintain. Terraform plans, terraform state, Kubernetes
+ manifests, Infracost breakdowns and arbitrary JSON are all evaluated the same way.
+
+ -
+ Cost, before the change is applied. Point Tirith at an
+
infracost breakdown and gate on the monthly or hourly total of the resources the
+ plan would create.
+
+ -
+ Sensitive values masked on your own runner, before anything leaves it — so a
+ value marked
sensitive stays out of the report and out of any upload.
+
+ -
+ An exit code your pipeline can act on.
3 means a policy said no;
+ 1 means Tirith could not tell you either way. A job that treats every non-zero
+ code alike cannot tell a working gate from a broken one.
+
+ -
+ The plan and the code, kept together. In platform mode each run uploads the
+ masked documents alongside the terraform source they describe, so a finding can still be read
+ against the code that caused it later on.
+
+ -
+ One policy set, many pipelines. Because Tirith is a CLI rather than an
+ integration built into one CI system, the same policies gate a GitHub Actions job, a GitLab job
+ and a laptop. In platform mode, Tirith rules and Checkov findings come back in a single
+ verdict.
+
+
+
+
+
+
+ Works with
+
+ -
+ GitHub Actions — a native action that finds the plan, posts a sticky
+ pull-request comment, creates a check run and sets the exit code:
+ tirith-iac-governance-action.
+
+ -
+ GitLab CI, and any container-based CI — install the CLI in the job and call it
+ directly, which is all the action does underneath. There is no GitLab-native equivalent of the
+ action.
+
+ -
+ Your machine — the same command, the same verdict, no account and no network.
+
+ -
+ Azure DevOps — not supported today.
+
+
+
+
+
+
+ Keeping policy in one place
+
+ Everything above works with policy files committed to your repository. If you would rather not
+ copy those files into every repository that needs gating,
+ tirith platform check evaluates against the policies a
+ StackGuardian organization enforces instead — same
+ document, same verdict, same exit codes, plus a central run history. That mode is optional, and
+ is the only part that talks to a network.
+
+
+
+
+
+
+