Scrydon
Examples

FOIA Precedent

Government FOIA precedent library — workspace KB learnings condense into a PrecedentLearning domain with records retention, auto-approve on publish, and PII redaction via markings.

The FOIA Precedent pack demonstrates the org-KB learnings exchange in a government records context. FOIA case teams capture case notes, legal holdings, and redaction rationales in a workspace knowledgebase; on finalization, the platform condenses them into PrecedentLearning records — holdings, citations, and precedent categories — that land in an org domain with records retention, auto-approval on publication, and PII redaction via security markings.

What the pack provisions

WhatDetail
PrecedentLearning object typeProperties: title (string), holding (text), citation (string), category (string: disclosure / exemption / fee-waiver / timing)
foia_precedents governed domainretentionDays set (records-retention policy), auto-approve on publish (requiredApprovals: 0), PII redaction via security markings
"FOIA Determination" process flowFinal stage approval action with promoteToOrgKb: true; knowledge.promotionTargetfoia_precedents / PrecedentLearning

Installing the pack provisions both the governed foia_precedents domain and the FOIA Determination process flow. Starting a template instance auto-creates a workspace KB linked to foia_precedents. The full case-to-precedent-library journey works from the download.

Download

Install

IT admin, once: open Settings → Platform → Packs, upload foia-precedent.scrydon-pack.tar.gz, and click Upload. The PrecedentLearning object type and the org-scoped foia_precedents domain are provisioned immediately, and the FOIA Determination process flow is made available org-wide.
Workspace admin: open Marketplace in the agentic sidebar and click Add on FOIA Determination to opt this workspace in (per-workspace, not per-environment).
Under Process Flows, find FOIA Determination and click Start. Name the instance after the request batch or case series (e.g. FY26 Exemption Cases). The platform auto-creates a workspace knowledgebase linked to foia_precedents / PrecedentLearning.
Upload case summaries, redaction rationale memos, and legal analysis documents into the workspace KB.

Learnings flow — auto-approve on publish

Finalize the workspace KB: either via the final approval action on the bundled FOIA Determination template (the publishing stage already carries promoteToOrgKb: true), or via the Workspace-Admin Promote learnings button.
The platform gathers all workspace KB pages, DLP-scans them, runs one LLM pass over the corpus, and extracts a set of discrete PrecedentLearning records shaped to holding, citation, and category.
Each learning is DLP-scanned and enqueued via the org-KB mutation queue.
Because foia_precedents has requiredApprovals: 0, learnings auto-approve and materialize immediately with no Review step. Publication is the gate; the Review queue is not used for this domain.

Auto-approve is appropriate here because the FOIA process itself is the review gate. A FOIA case is reviewed, redacted, and published by the case team before finalization is triggered. By the time the platform condenses the workspace KB, the content has already passed human review. The Review queue adds no additional value.

PII redaction via security markings

FOIA cases often involve personal information that must be redacted from published precedents. The foia_precedents domain uses security markings to gate access to PII-sensitive properties:

  • Properties tagged with the pii marking are visible only to members who hold the pii marking.
  • In a published precedent, the holding text is authored to exclude PII (by the case team during the FOIA redaction step); the raw case note from which it was derived stays in the workspace KB, which is not published to the org domain.
  • If a holding still contains PII (e.g. a name), DLP scanning will flag it before materialization. Configure your DLP policy to block PII in holding fields for this domain.

Records retention

The foia_precedents domain has a retentionDays value set. After the retention period expires, the platform flags eligible rows during the retention sweep. Deletion still requires an explicit org-admin action — the sweep identifies candidates but does not delete autonomously.

Retention sweep identifies; it does not delete. The sweep marks rows whose retentionDays has elapsed as eligible for deletion and surfaces them under Settings → Organization → Knowledgebase → Retention. An org admin must confirm each deletion explicitly.

Governance at a glance

PolicySetting
Review gateNone (requiredApprovals: 0 — auto-approve on publish)
PII access controlSecurity markings on PII-sensitive properties
Records retentionretentionDays (sweep identifies; explicit org-admin action deletes)
Re-finalize behaviorUpsert by stable learning key — safe across iterative case additions

What's interesting about it

  • Auto-approve with no Review queue. requiredApprovals: 0 means learnings materialize immediately on finalization. This is appropriate when the publishing stage of the FOIA process IS the review gate — no duplicate human review step is needed.
  • Retention-aware domain. The retentionDays value enables records-lifecycle governance. Precedents that have exceeded their retention period are flagged for explicit disposal.
  • category classifies by FOIA law area. disclosure / exemption / fee-waiver / timing maps to the four main FOIA response categories, making the precedent library browsable by legal staff.
  • References trace precedents to case documents. Each PrecedentLearning.references entry links to the workspace KB page (case summary, legal memo) from which the holding was derived.
On this page

On this page