Posturizer

Posturizer drafts policy text from evidence you already have. It reads the compliance clauses extracted from your uploaded documents, the controls they map to, and the frameworks you have activated, then produces draft policies in which every factual claim is scored against your source clauses. Claims it cannot ground are flagged rather than hidden. A draft is a starting point for human review, not a finished, approved policy — and never a certification of compliance.

What it works from

Posturizer reasons only over your own material. The deterministic part of the pipeline runs inside the Rails application first: it classifies and extracts clauses from your documents, embeds them, and maps each clause to the controls it satisfies. That gives the agent three structured inputs:

• Your activated frameworks — the frameworks your tenant has turned on, which determine the policy templates in scope (see Frameworks & controls).
• Mapped controls and source clauses — the extracted clauses, each carrying its text and the control IDs it maps to (for example CC6.1, A.5.15, 164.312).
• Company context — light tenant context used to fill template fields, not to invent facts.

The reasoning tail is delegated to a Google ADK agent running on Vertex AI (Gemini 2.5). Rails keeps the deterministic head and the security authority; the agent only reasons over what Rails sends it.

The three stages

1. Framework recommendation

Before drafting anything, the agent reasons over your clauses to recommend which frameworks your evidence actually supports. It does this from evidence only: it scans each clause's control IDs for known prefixes — CC and related criteria for SOC 2, A.for ISO 27001 Annex A, 164. for HIPAA, numeric IDs for PCI DSS — and checks clause text for explicit framework mentions. A framework is recommended only when there is evidence for it in your clauses. The agent will not infer a framework from your company name, industry, or sector. The output is a list of frameworks, a short reasoning string, and per-clause citations.

2. Generation

For each in-scope template, the agent drafts the policy text from the template structure and the clauses mapped to that template's controls. Generation produces draft markdown, a confidence score, a set of claim citations linking statements back to the clauses that support them, and divergence flags for sections your evidence does not cover.

3. Grounding and self-correction

Each draft is then checked claim by claim. The grounding step splits the draft into atomic factual claims and scores each one against your source clauses using embedding similarity (Gemini embeddings). Claims are bucketed by score:

• Supported — score at or above 0.85. The claim is well grounded in your clauses.
• Flagged — score between 0.4 and 0.85. Grounded weakly enough to warrant a human look.
• Unsupported — score below 0.4. The claim is not adequately backed by your clauses.

These thresholds were calibrated against a live embedding run over the demo corpora, not chosen arbitrarily. When grounding reports unsupported claims, the agent regenerates the draft and re-grounds it, up to three iterations, so the self-correction loop can lift weak claims before a human sees them. The agent records a per-pass snapshot, so the first-pass and final grounding scores are both reported and the improvement is visible rather than assumed.

What you get back

Each completed template comes back as a draft with its grounding attached. The Rails application persists it as a PolicyGeneration record in draftstatus, carrying:

• The draft markdown — the generated policy text.
• Claim citations — the claims that grounded cleanly, each linked to the source clause and its score.
• Flagged and unsupported claims — kept separately so reviewers can see exactly what the agent was unsure of, rather than having it quietly dropped.
• Divergence flags — sections where your current evidence diverges from, or does not cover, what the template expects. These become reviewable PostureDivergence records describing the current state, the recommended state, and a rationale.
• An overall confidence score for the draft.

Alongside the per-draft results, a run reports aggregate self-correction stats: total supported, flagged, and unsupported claim counts, and the first-pass versus final grounding averages across all drafts.

How it fits the policy workflow

A Posturizer run does not publish policies. It produces drafts that enter a review lifecycle:draft → reviewing → published or rejected. A person reads the draft, weighs the flagged and unsupported claims, resolves the divergences, and decides. Only on explicit approval does a draft become a published Policywith a version record. The drafts are grounded candidates that make review faster and more honest; they are not a substitute for it.

Honest boundaries

Posturizer is deliberately scoped. It is worth being precise about what it does not do:

• It drafts policy candidates grounded in your evidence. It does not decide that you are compliant, and it does not certify anything to an auditor.
• Grounding is embedding similarity against your clauses, not legal judgment. A high score means a claim resembles your source material closely; it does not mean the claim is legally sufficient. That judgment stays with your reviewer.
• It only reasons over the clauses you provide. If your evidence is thin, drafts will carry more flagged claims and more divergence flags — which is the intended behaviour, not a defect.
• Nothing is published without human approval. The agent has no authority to change your live policies; Rails holds that authority.

See also Evidence-as-code for how the evidence Posturizer reasons over is collected and kept current, and Frameworks & controls for how clauses map to the controls that drive recommendation and generation.