|
| 1 | +# Edictum Docs Style & Terminology Guide |
| 2 | + |
| 3 | +This is the binding reference for all documentation writers. Every page must use these terms consistently. |
| 4 | + |
| 5 | +## Canonical Terms (USE THESE, NOT THE ALTERNATIVES) |
| 6 | + |
| 7 | +| Concept | Canonical Term | DO NOT USE | |
| 8 | +|---------|---------------|------------| |
| 9 | +| The YAML constructs that define rules | **contract** / **contracts** | policies, rules, guards, checks | |
| 10 | +| What Edictum does to tool calls | **enforces contracts** | governs, guards, protects, secures | |
| 11 | +| When a contract blocks a call | **denied** / **deny** | blocked, rejected, prevented, stopped | |
| 12 | +| When a contract allows a call | **allowed** / **allow** | passed, approved, permitted | |
| 13 | +| The runtime check sequence | **pipeline** | engine, evaluator, processor, middleware | |
| 14 | +| The sequence: preconditions -> execute -> postconditions -> audit | **pipeline** (describe the steps, don't rename them) | workflow, chain, flow | |
| 15 | +| What agents do that Edictum checks | **tool call** / **tool calls** | function call, action, operation, invocation | |
| 16 | +| The thin framework-specific integration layer | **adapter** / **adapters** | integration, plugin, connector, driver | |
| 17 | +| Shadow-testing without blocking | **observe mode** | shadow mode, dry run, passive mode, monitor mode | |
| 18 | +| The identity context on a tool call | **principal** | user, identity, caller, actor | |
| 19 | +| The structured output from postconditions | **finding** / **findings** | result, detection, alert, violation | |
| 20 | +| The YAML file containing contracts | **contract bundle** | policy file, rule file, config | |
| 21 | +| What Edictum IS | **runtime contract enforcement for agent tool calls** | governance framework, safety library, guardrails | |
| 22 | + |
| 23 | +## The One-Liner |
| 24 | + |
| 25 | +Use this exact framing (or close paraphrase) when describing what Edictum is: |
| 26 | + |
| 27 | +> Edictum enforces contracts on AI agent tool calls -- preconditions before execution, sandbox allowlists for file paths and commands, postconditions after, session limits across turns, and a full audit trail. Contracts are YAML. Enforcement is deterministic. The agent cannot bypass it. |
| 28 | +
|
| 29 | +## The Core Metaphor |
| 30 | + |
| 31 | +Edictum sits at the **decision-to-action seam**. The agent decides to call a tool. Before that call executes, Edictum checks it against contracts. This is a hard boundary, not a suggestion. |
| 32 | + |
| 33 | +DO NOT use metaphors like: gatekeeper, guardian, shield, firewall, sentinel, watchdog. |
| 34 | +DO use: "hard boundary," "enforcement point," "the check between decision and action." |
| 35 | + |
| 36 | +## Writing Rules |
| 37 | + |
| 38 | +1. **Lead with the problem, then the solution.** Not "Edictum has X" but "Agents do Y bad thing. Edictum prevents this by..." |
| 39 | +2. **Show, don't describe.** Every concept page: working example within the first screen. |
| 40 | +3. **No marketing language.** No "powerful," "seamless," "revolutionary," "robust," "elegant." Just say what it does. |
| 41 | +4. **Short paragraphs.** 2-3 sentences max. |
| 42 | +5. **Code examples must be copy-pasteable.** If it doesn't work when pasted, delete it. |
| 43 | +6. **Deterministic, not probabilistic.** Emphasize that contracts are code, not suggestions. The LLM cannot talk its way past a contract. |
| 44 | + |
| 45 | +## Pipeline Description (USE THIS CONSISTENTLY) |
| 46 | + |
| 47 | +When describing what happens on every tool call: |
| 48 | + |
| 49 | +1. Agent decides to call a tool |
| 50 | +2. Edictum evaluates **preconditions** against the call's arguments and principal |
| 51 | +3. If any precondition fails: **deny** (call never executes) |
| 52 | +4. Edictum evaluates **sandbox contracts** against allowlist boundaries (file paths, commands, domains) |
| 53 | +5. If the call falls outside any sandbox boundary: **deny** or **pending_approval** (depending on `outside` setting) |
| 54 | +6. If all pass: tool executes |
| 55 | +7. Edictum evaluates **postconditions** against the tool's output |
| 56 | +8. Postcondition failures produce **findings**. With `effect: warn`, the tool result is unchanged. With `effect: redact` or `effect: deny`, the pipeline modifies the output for READ/PURE tools (WRITE/IRREVERSIBLE tools fall back to warn) |
| 57 | +9. **Audit event** is emitted for every evaluation (allowed, denied, or observed) |
| 58 | + |
| 59 | +Session limits (max calls, per-tool caps, attempt limits) are checked as part of steps 2-5. |
| 60 | + |
| 61 | +## What Edictum is NOT (be honest about these) |
| 62 | + |
| 63 | +- NOT prompt engineering or input guardrails (those filter what goes INTO the LLM) |
| 64 | +- NOT output content filtering (that filters what comes OUT of the LLM) |
| 65 | +- NOT an authentication/authorization system (it accepts a Principal but doesn't authenticate) |
| 66 | +- NOT ML-based detection (contracts are deterministic pattern matching) |
| 67 | +- NOT a proxy or network-level tool (it's an in-process library) |
| 68 | + |
| 69 | +## Page Structure Pattern |
| 70 | + |
| 71 | +Every page should follow: |
| 72 | + |
| 73 | +1. **Opening**: 1-2 sentences stating the problem this page addresses |
| 74 | +2. **Example**: Working code/YAML within the first visible screen |
| 75 | +3. **When to use this**: Concrete scenarios where this feature applies — real situations a user would recognize (e.g., "Your fintech agent needs to limit daily transaction approvals" not "This feature provides configurable limits"). Include: |
| 76 | + - 2-4 concrete scenarios with brief descriptions |
| 77 | + - Which user persona benefits (developer debugging vs. platform team in production) |
| 78 | + - How this relates to other Edictum features (e.g., "Use callbacks for immediate reactions, OTel for historical dashboards") |
| 79 | +4. **Explanation**: How it works, why it matters |
| 80 | +5. **Reference**: Full details, edge cases, configuration |
| 81 | +6. **Next steps**: Links to related pages |
| 82 | + |
| 83 | +## Cross-Reference Conventions |
| 84 | + |
| 85 | +- Link to concepts pages for explanations: `[contracts](../concepts/contracts.md)` |
| 86 | +- Link to reference pages for syntax: `[YAML reference](../contracts/yaml-reference.md)` |
| 87 | +- Link to adapter pages by name: `[LangChain adapter](../adapters/langchain.md)` |
| 88 | +- Always use relative paths for internal links |
0 commit comments