Policy-as-Code Starter for SEA™ Forge

This guide provides patterns and templates for authoring governance policies in SEA™ DSL.

1. SEA™ DSL Policy Fundamentals

1.1 Policy Structure

policy <PolicyName>:
  it is <modality> that <subject>
    <conditions>
    <timing>

Modalities:

• obligatory — Must happen
• prohibited — Must not happen
• permitted — May happen (optional)

1.2 Basic Policy Patterns

Mandatory Action:

policy ApprovalRequired:
  it is obligatory that each HighValueTransaction
    has approval_status = approved
    before processing

Prohibited Action:

policy NoUnauthorizedAccess:
  it is prohibited that any User
    with role != admin
    performs system_configuration_change

Conditional Permission:

policy TestDeployment:
  it is permitted that Developer
    with environment = test
    performs deployment
    without approval

2. Common Governance Patterns

2.1 Data Governance

context DataGovernance:

  policy PIIProtection:
    it is obligatory that each DataRequest
      containing pii = true
      has encryption = enabled
      has access_log = created

  policy DataMinimization:
    it is obligatory that each DataCollection
      has purpose = documented
      has retention_period = defined
      has unnecessary_fields = removed

  policy ConsentRequired:
    it is obligatory that each PersonalDataProcessing
      has consent = obtained
      has consent_timestamp = recorded
      before processing

2.2 AI Output Governance

context AIOutputGovernance:

  policy ContentSafety:
    it is prohibited that any AIOutput
      contains harmful_content = true
      OR contains bias_detected = true
      OR contains copyright_violation = true

  policy HallucinationPrevention:
    it is obligatory that each FactualClaim
      has source_citation = provided
      has confidence_score >= 0.85

  policy HumanReviewRequired:
    it is obligatory that each AIDecision
      with impact_level = high
      has human_review = completed
      before execution

2.3 Access Control

context AccessControl:

  policy RoleBasedAccess:
    it is obligatory that each SystemAccess
      has user_role = verified
      has access_level <= role_permission_level

  policy PrivilegedActionAudit:
    it is obligatory that each PrivilegedAction
      has audit_log = created
      has actor_id = recorded
      has timestamp = captured
      has justification = documented

  policy SessionTimeout:
    it is obligatory that each UserSession
      with idle_time > 30_minutes
      is terminated

2.4 Compliance Governance

context ComplianceGovernance:

  policy GDPRCompliance:
    it is obligatory that each EUUserData
      has lawful_basis = documented
      has data_subject_rights = enabled
      has cross_border_transfer = compliant

  policy SOXCompliance:
    it is obligatory that each FinancialRecord
      has audit_trail = complete
      has modification_history = preserved
      has access_control = enforced

  policy HIPAACompliance:
    it is obligatory that each PHI
      has encryption = at_rest_and_in_transit
      has access_log = maintained
      has minimum_necessary = applied

3. Advanced Patterns

3.1 Temporal Constraints

policy TimeBasedApproval:
  it is obligatory that each UrgentRequest
    has approval = granted
    within 1_hour
    by authorized_approver

policy RetentionEnforcement:
  it is obligatory that each AuditLog
    is retained for 7_years
    with immutability = guaranteed

3.2 Escalation Chains

policy EscalationChain:
  it is obligatory that each UnresolvedIssue
    with age > 4_hours AND severity = high
    has escalation_level = increased
    has manager_notified = true

policy AutomaticEscalation:
  it is obligatory that each CriticalIncident
    has immediate_notification = sent_to_oncall
    has incident_commander = assigned
    within 15_minutes

3.3 Multi-Condition Policies

policy ComplexApproval:
  it is obligatory that each LargeTransaction
    with amount > $100000
    AND destination = external
    AND frequency > once_per_day
    has dual_approval = obtained
    has compliance_review = completed
    has audit_flag = set

4. Policy Gateway Integration

4.1 Filter Configuration

Policies compile to Policy Gateway filters:

1
2
3
4
5
6
7
8
9
10
11
12
13
# Generated from SEA™ DSL
filters:
  - name: ContentSafety
    type: output
    conditions:
      - field: harmful_content
        operator: equals
        value: true
        action: block
      - field: bias_detected
        operator: equals
        value: true
        action: block

4.2 Runtime Enforcement

// This policy compiles to runtime filter
policy JailbreakPrevention:
  it is prohibited that any UserPrompt
    contains jailbreak_pattern = detected
    OR contains prompt_injection = detected

5. Validation Workflow

5.1 Author Policy

1
2
# Create policy file
vim docs/specs/<context>/policies.sea

5.2 Validate Syntax

1
just sea-validate docs/specs/<context>/policies.sea

5.3 Parse to AST

1
just sea-parse docs/specs/<context>/policies.sea

5.4 Integrate with SDS

1
2
3
4
5
6
7
8
# In SDS document
governance:
  policies:
    - ref: policies.sea
      rules:
        - PIIProtection
        - ContentSafety
        - HumanReviewRequired

5.5 Deploy

1
2
just pipeline <context>
just ci

6. Testing Policies

6.1 Unit Testing

test PIIProtectionTest:
  given DataRequest with pii = true, encryption = disabled
  expect policy_violation = true

test ContentSafetyTest:
  given AIOutput with harmful_content = false
  expect policy_violation = false

6.2 Integration Testing

1
2
3
4
# Test with Policy Gateway
curl -X POST http://localhost:8080/test \
  -H "Content-Type: application/json" \
  -d '{"prompt": "test prompt", "test_mode": true}'

7. Best Practices

7.1 Naming Conventions

• Use PascalCase for policy names: PIIProtection
• Use snake_case for conditions: has_approval
• Use descriptive names: HighValueTransactionApproval

7.2 Policy Organization

1
2
3
4
5
docs/specs/<context>/
├── domain.sea          # Domain entities
├── policies.sea        # Governance policies
├── events.sea          # Domain events
└── invariants.sea      # System invariants

7.3 Documentation

// Policy: Ensures all high-value transactions are approved
// Compliance: SOX Section 404, Internal Control Requirement
// Author: Compliance Team
// Last Updated: 2026-01
policy HighValueTransactionApproval:
  ...