---
id: FLEX-WP-0003
type: workplan
title: "Markitect Consumer Integration"
domain: netkingdom
status: todo
owner: flex-auth
topic_slug: flex-auth
planning_priority: P1
planning_order: 30
depends_on_workplans:
  - FLEX-WP-0002
related_workplans:
  - MKTT-WP-0014
created: "2026-05-04"
updated: "2026-05-17"
state_hub_workstream_id: "c0a6c9f6-bb6b-416d-b537-f30504c63d75"
---

# FLEX-WP-0003: Markitect Consumer Integration

## Purpose

Make Markitect the first concrete protected-system consumer of flex-auth.

Markitect already has a local enterprise integration boundary in
`MKTT-WP-0014`: identity claim normalization fixtures, policy-subject mapping,
resource manifests, local decision-log sink, workflow declarations, and CLI
inspection. This flex-auth workplan implements the service-side contract that
Markitect can call.

This workplan is also the first concrete CARING benchmark for flex-auth.
Markitect resource/action fixtures should prove that a protected system can
map local resource semantics into CARING access descriptors without making
Markitect-specific assumptions part of the generic core.

## P3.1 - Define Markitect resource namespace

```task
id: FLEX-WP-0003-T001
status: todo
priority: high
state_hub_task_id: "53f2fa67-780b-4e40-bbda-e669e4cecc32"
```

Define resource types and hierarchy for Markitect:

```text
knowledge_base
  -> repository
  -> document/path
  -> section/span
  -> context_package
  -> workflow_artifact/export
```

Output: namespace docs, schema examples, and compatibility notes for
Markitect frontmatter and backend metadata. The namespace docs must map
each resource level to CARING scope and plane values.

## P3.2 - Import Markitect resource manifests

```task
id: FLEX-WP-0003-T002
status: todo
priority: high
state_hub_task_id: "90082eaf-37f5-492f-a884-ff8eec0eccaa"
```

Accept the Markitect-side `FlexAuthResourceManifest` shape and import it into
the flex-auth registry.

Output: importer, validation diagnostics, example fixtures, and tests.
Diagnostics should include missing or ambiguous CARING classification when a
manifest cannot be mapped cleanly enough for conformance checks.

## P3.3 - Define Markitect action vocabulary

```task
id: FLEX-WP-0003-T003
status: todo
priority: high
state_hub_task_id: "cfc78bbb-5425-4780-a860-9109df62ea37"
```

Define actions:

- `read`
- `query`
- `search`
- `package`
- `activate_context`
- `export`
- `workflow_run`
- `admin`

Map these actions to Markitect policy-gateway decisions.
Also map each action to CARING capabilities and exposure modes, keeping
`view`/`read` separate from `export`, and keeping plaintext, masked, and
metadata-only exposure explicit.

## P3.4 - Implement Markitect check fixtures

```task
id: FLEX-WP-0003-T004
status: todo
priority: high
state_hub_task_id: "1d5de3b2-c581-4ca3-9107-93211eb02c6b"
```

Create fixtures that mirror Markitect examples:

- public document allow
- internal document deny
- internal document allow for reader group
- restricted export requires steward role and MFA
- context package activation includes policy version and freshness metadata

Each fixture should include the expected CARING descriptor, conformance
finding set, and exposure/audit behavior.

## P3.5 - Add Markitect adapter contract tests

```task
id: FLEX-WP-0003-T005
status: todo
priority: medium
state_hub_task_id: "f9297b0d-69dc-495c-a650-ca671f2c59c7"
```

Add tests that produce flex-auth decisions in the shape Markitect expects:

- `allow`
- `deny`
- `redact`
- `audit_denied`
- reason and rule id
- policy version
- resource metadata
- obligations/diagnostics
- CARING descriptor and conformance findings

## P3.6 - Document integration flow

```task
id: FLEX-WP-0003-T006
status: todo
priority: medium
state_hub_task_id: "e34b0303-4416-40a3-8b34-e0e80d644aea"
```

Document how Markitect should:

1. Publish resources.
2. Submit check or batch_check requests.
3. Enforce allow/deny/redact.
4. Record decision ids.
5. Explain decisions back to users.

The documented flow should explain how Markitect local roles, groups,
frontmatter, and workflow states map into CARING dimensions before they
become flex-auth decisions.

## Exit Criteria

- flex-auth can ingest Markitect resource manifests.
- flex-auth can return Markitect-compatible decisions.
- Markitect examples can be represented in flex-auth fixtures.
- Integration remains generic enough for other protected systems.
- Markitect local semantics can be represented as CARING descriptors and
  conformance findings without custom core concepts.