Refine workplans for CARING profile

workplans/FLEX-WP-0003-markitect-consumer-integration.md

@@ -13,7 +13,7 @@ depends_on_workplans:
 related_workplans:
   - MKTT-WP-0014
 created: "2026-05-04"
-updated: "2026-05-04"
+updated: "2026-05-17"
 state_hub_workstream_id: "c0a6c9f6-bb6b-416d-b537-f30504c63d75"
 ---
 
@@ -29,6 +29,11 @@ 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
@@ -50,7 +55,8 @@ knowledge_base
 ```
 
 Output: namespace docs, schema examples, and compatibility notes for
-Markitect frontmatter and backend metadata.
+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
 
@@ -65,6 +71,8 @@ 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
 
@@ -87,6 +95,9 @@ Define actions:
 - `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
 
@@ -105,6 +116,9 @@ Create fixtures that mirror Markitect examples:
 - 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
@@ -124,6 +138,7 @@ Add tests that produce flex-auth decisions in the shape Markitect expects:
 - policy version
 - resource metadata
 - obligations/diagnostics
+- CARING descriptor and conformance findings
 
 ## P3.6 - Document integration flow
 
@@ -142,9 +157,15 @@ Document how Markitect should:
 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.