---
id: FLEX-WP-0002
type: workplan
title: "Standalone Policy-as-Code Core"
domain: netkingdom
status: todo
owner: flex-auth
topic_slug: flex-auth
planning_priority: P0
planning_order: 20
depends_on_workplans:
  - FLEX-WP-0001
created: "2026-05-04"
updated: "2026-05-04"
state_hub_workstream_id: "aa60e183-9a87-4e03-99b0-15786bfa11ae"
---

# FLEX-WP-0002: Standalone Policy-as-Code Core

## Purpose

Implement the standalone flex-auth core: resource registry, subject/group/team
registry, relationship facts, policy packages, deterministic check APIs,
decision envelopes, explainability, local decision logs, and CLI/service entry
points.

This is the first implementation workplan. It should produce a useful local
authorization system before delegating to Topaz, OpenFGA, OPA, or other
external policy engines.

## Design Direction

The core should define flex-auth's own stable vocabulary:

```text
subject + action + resource + context + policy version -> decision
```

Backends may change later, but these envelopes must stay stable:

- protected system
- resource namespace and hierarchy
- action vocabulary
- subject/group/team/tenant identity
- relationship facts
- policy package and version
- decision effect, reason, obligations, diagnostics, provenance

## P2.1 - Define canonical schemas

```task
id: FLEX-WP-0002-T001
status: todo
priority: high
state_hub_task_id: "534e5251-8529-48fe-8cf8-b3b6bc4ec1f4"
```

Define machine-readable schemas for:

- protected system manifest
- resource manifest
- subject/group/team manifest
- relationship fact manifest
- policy package
- policy fixture/test case
- check request
- decision envelope
- audit event

Output: docs, examples, schema files, and validation tests.

## P2.2 - Implement local registry store

```task
id: FLEX-WP-0002-T002
status: todo
priority: high
state_hub_task_id: "d8045124-f0ae-495d-87b5-24fd9528ef93"
```

Implement a local registry for systems, resources, subjects, groups, teams,
tenants, and relationships.

Start with a deterministic file-backed or SQLite-backed store that supports
tests and local development.

## P2.3 - Implement policy package loader and validator

```task
id: FLEX-WP-0002-T003
status: todo
priority: high
state_hub_task_id: "09be0f25-e5ba-42b5-8b2f-36fd0ef2fe6b"
```

Load policy-as-code packages with metadata, rules, fixtures, tests, and
activation metadata.

The first implementation may use a simple declarative rule format as long as
the package boundary leaves room for OPA/Rego, Cedar, and Topaz later.

## P2.4 - Implement deterministic check and batch_check APIs

```task
id: FLEX-WP-0002-T004
status: todo
priority: high
state_hub_task_id: "f6427575-00af-4f3e-ab30-5b9a158343ef"
```

Implement:

```text
check(subject, action, resource, context) -> decision
batch_check(subject, action, resources, context) -> decisions
```

Decisions must include effect, reason, matched policy version, matched rule,
resource metadata, subject metadata, obligations, diagnostics, and provenance.

## P2.5 - Implement list_allowed and explain

```task
id: FLEX-WP-0002-T005
status: todo
priority: medium
state_hub_task_id: "e8fcbabd-4eb6-41d2-a4d5-6f40cc245a7e"
```

Implement:

```text
list_allowed(subject, action, resource_type, filters, context)
explain(decision_id)
```

Use the same decision model as `check` and keep explanations useful for policy
authors and protected-system developers.

## P2.6 - Add local decision log

```task
id: FLEX-WP-0002-T006
status: todo
priority: medium
state_hub_task_id: "2def10c1-4b5f-44a8-8e6b-4c8592fffd43"
```

Persist compact JSONL or SQLite decision logs for local development and audit
experiments. Always record denies, redactions, exports, and emergency actions.

## P2.7 - Add CLI and service skeleton

```task
id: FLEX-WP-0002-T007
status: todo
priority: high
state_hub_task_id: "ee9ae6dd-c31f-4d4e-b238-533a2b8040d4"
```

Provide command-line workflows for:

- validate manifests
- load registry data
- test policy packages
- check one request
- batch check
- explain a decision

Add a minimal service skeleton only after CLI/library behavior is stable.

## P2.8 - Add tests and examples

```task
id: FLEX-WP-0002-T008
status: todo
priority: high
state_hub_task_id: "6cbe572a-2877-4936-8ef3-63b79900fae2"
```

Add examples for local users, groups, teams, project resources, inherited
relationships, and policy fixtures.

## Exit Criteria

- flex-auth can run standalone for local development.
- Policy packages are versioned, validated, and testable.
- Resource registration and relationship facts can drive authorization.
- `check`, `batch_check`, `list_allowed`, and `explain` are implemented.
- Decision output is stable enough for protected systems to integrate against.