Manage policies

Policies are the customer input that makes Ledgix useful. Before you focus on SDK syntax, make sure your team has uploaded the policy text or rules that should actually govern the action you are protecting.

Choose the right policy source

You can give Ledgix policy content in four practical ways:

1. 01

   Upload a file

   Use the customer dashboard Upload page for PDFs, DOCX files, text files, Markdown, JSON, or CSV documents that already exist in your workflow.
2. 02

   Paste policy text

   Use pasted text when the source material is small or when you want to test a rule set before formalizing it into a file.
3. 03

   Register structured rules

   Use `POST /register-policy` when your application already stores a small, explicit rule set that you want to send directly over the API.
4. 04

   Import from Confluence

   Use the optional Confluence import flow if your SOPs already live there and you want the dashboard to pull a page into your policy library.

Recommended customer workflow

1. Pick one high-value policy for the first guarded action.
2. Give it a stable policy_id so your SDK requests can reference it consistently.
3. Keep the document narrow enough that reviewers can understand it quickly.
4. Update the policy source when the business rule changes instead of working around stale text in code.

Uploading policy content in the dashboard

The dashboard Upload page is the primary path for most customers. It supports:

• a human-readable document name
• an optional policy_id override
• file upload
• pasted policy text
• optional Confluence imports once workspace credentials are saved in Settings

Use the Policies view afterward to confirm the uploaded source is the one your team expects to rely on.

Registering rules over HTTP

Use the API when your policy is already stored as structured rules in your application.

POST /register-policy HTTP/1.1
Host: vault.example.com
Content-Type: application/json
X-Vault-API-Key: sk_prod_example
 
{
  "policy_id": "payments-prod",
  "description": "Controls automated payment creation",
  "rules": [
    "Payments must be tied to a valid order event.",
    "Automated payments above $1000 require manual review.",
    "Payment methods must use tokenized identifiers."
  ],
  "tools": ["create_stripe_payment"]
}

Referencing a policy from the SDK

The easiest way to keep the request clear is to pass the policy_id in the request context.

const clearance = await client.requestClearance({
toolName: "create_stripe_payment",
toolArgs: input,
agentId: "payments-agent",
sessionId: "checkout-42",
context: { policy_id: "payments-prod" },
});

Optional Confluence imports

Confluence import is useful when your team already maintains operational rules there.

Before importing:

• save the workspace URL, username or email, and API token in Settings
• choose whether you want a document name or policy_id override
• make sure the page contains real policy text, not navigation or meeting notes

What reviewers see later

Uploaded or registered policy content shows up indirectly during review:

• Ledgix cites the policy that influenced the decision
• reviewers can inspect the reason and the supporting excerpts
• the policy_id lets your team trace a decision back to the source you intended

This is why stable naming matters. If your policy IDs drift, the review queue becomes harder to reason about.

Common policy-management mistakes

• Uploading broad handbooks when the first integration needs one precise rule set.
• Reusing the same policy_id for unrelated tools.
• Forgetting to update the policy source after operational rules change.
• Importing a Confluence page before saving valid Confluence credentials in Settings.
• Expecting better decisions from placeholder policy text than from the real rule your reviewers actually use.