PurposeMesh

1. Executive summary

The requirement fits PurposeMesh, but the secure answer is not “RBAC everywhere.” It is a small functional-role model combined with business DataScope, resource relationships, purpose, classification, time, and target-native enforcement.

Open-source release status · Technical Preview: use this build to evaluate the model, API, local enforcement behavior, lifecycle controls, and contributor contract. Do not use it as a production authorization control plane. The preview has no compatibility or support guarantee, enterprise identity path, multi-tenant control store, or externally verified target adapter. Every future production claim requires linked conformance evidence.

Target business outcome: SAP, BW, Elasticsearch, ADF, application, and BI pipelines can land in one governed store while each team receives a different server-enforced row and field view. Five capability personas stay stable: Viewer, Operator, Data Steward, Security Auditor, and Platform Admin. A Contract Capsule says exactly which resource, rows, fields, actions, purpose, conditions, and obligations are allowed. Removing a team revokes the implemented local desired-state relationship once; verified removal at external enforcement points requires conformant adapters with published evidence, successful revoke, and matching target read-back.

Target product outcome: PurposeMesh becomes an authorization delivery and assurance plane. It evaluates new applications through a PDP and compiles legacy/data-platform policy through conformant adapters. A fidelity firewall refuses any translation that would weaken row, field, masking, purpose, JIT, or audit semantics.

Truth as of this build: standing row and field policy works in the local core and SQLite warehouse. The console, API, minimal AuthZEN evaluation adapter, local persistence, policy explanation, lifecycle workflow, reusable content-addressed role objects, and staged workload contracts are real. Native-shaped compiler artifacts are previews; seeded fidelity gates block execution and keep apply/revoke/read-back arrays empty. External SAP, BW, Elasticsearch, ADF, warehouse-native, and BI changes are not. There is no enterprise OIDC/SCIM, catalog/lineage crawler, connector worker, target read-back, drift reconciliation, or multi-replica control store yet.

How PurposeMesh fits with established authorization systems

PurposeMesh does not claim to replace established policy engines, relationship systems, or native enforcement controls. Its intended layer is the delivery and assurance work around them: one reviewable DataScope contract, refusal of lossy target translations, governed lifecycle changes, and evidence that a target still matches policy. That differentiation remains a product hypothesis until external adapters and adopters validate it.

Claim boundary: RBAC, ABAC, ReBAC, purpose constraints, policy decision points, row security, field controls, JIT access, and reconciliation are established patterns. PurposeMesh’s proposal is their contract-and-evidence composition across heterogeneous applications and data platforms—not a claim to have invented those primitives or to be the only product combining them.

Real product walkthrough

See the working reference flow establish identity, release a server-authorized data view, explain the active boundary, compare tenant-scoped results, author least-privilege access, and enter independent review.

Watch or download the complete MP4 Follow the verification script

Product surfaces

What this demonstrates: these are real local application paths backed by the tested reference API and policy core. External platform adapters remain preview-only until apply, read-back, rollback, drift, and equivalence gates pass.

2. Problem statement

Enterprises move sensitive data through SAP S/4HANA, SAP BW, ADF, search, application APIs, warehouses, and BI tools. Several pipelines can feed one physical store, but every human and workload identity is entitled to a different combination of records, fields, actions, purpose, and duration.

The authorization plane must also know what data exists, who owns it, how it is classified, where it flows, and which access paths can bypass policy. PurposeMesh can make decisions only from registered and trusted metadata; production discovery connectors and steward approval are therefore part of the control, not optional inventory work.

Consider one unified operational store fed through several independent paths:

• Vendor Operations sees assigned purchasing organizations and plants, with vendor identifiers masked.
• L1 support sees health, counts, timestamps, and sanitized errors—not vendor PII or raw payload.
• L2 BW can monitor or retry selected chains without receiving unrelated vendor rows.
• Platform Operations sees cross-team technical telemetry but no business payload.
• Finance Audit receives clear vendor identifiers only for an approved case and bounded time.
• Unified Data Owner can inspect the complete synthetic source only through an explicit data-governance contract; this is the controlled baseline for comparison.
• Platform Admin maintains connectors and policy but reads no business data by default.

Enforcement boundary: every data request is authorized server-side. Subject, purpose, action, resource, row predicates, and field projection are evaluated before the API releases a response.

The local seed demonstrates a smaller version: Emma and Finn share the Business consumer persona but different capsule attributes keep ACME and GLOBEX rows disjoint. Offboarding ACME removes Emma’s local desired-state path while Finn remains. That does not yet prove removal in an external BW role, Elasticsearch cluster, ADF factory, or BI workspace.

3. Use cases and discovery questionnaires

Use the following scenarios to validate product fit and the questionnaires to turn an application, dataset, or pipeline into an evidence-backed authorization design. Answers should name authoritative systems and owners; “unknown” becomes a fail-closed gap, not an assumed permission.

Use-case framing

Primary use case: one multi-pipeline store, many least-privilege views

S/4 vendor and purchasing data, BW process-chain events, Elasticsearch telemetry, ADF-loaded customer, transaction, and inventory data, ITSM tickets, and BOBJ operations land in one synthetic unified store containing 100,000 records by default. ACME, GLOBEX, support, application, data, and platform teams use the same physical target. The policy must isolate their rows and fields while preserving source, pipeline, and classification lineage.

Supporting use cases

Stakeholder questionnaires

Run these as separate interviews. Record the respondent, source system, evidence link, owner, confidence, and follow-up date for every answer.

Decision-ready exit criteria

• Every data response is authorized server-side; row predicates and field projection are applied before results leave the API.
• The default deterministic synthetic unified store contains at least 100,000 lineage-tagged records from multiple modeled source and pipeline families.
• Only an explicitly contracted Unified Data Owner receives the complete approved source; Platform Admin remains a zero-business-data role.
• Every protected operation requires an authenticated human or workload identity.
• A missing identity, purpose, scope, contract, classification, or enforcement capability denies access.
• Cross-tenant isolation is demonstrated with negative tests on the shared physical source.
• Every seeded role is tested at the network boundary: unauthorized rows and fields are absent from the response, not merely hidden in the interface.
• Account switching aborts in-flight work, clears previous rows and authorization metadata, establishes a new session, and requires a new explicit query.
• Platform administration provides no implicit business-data read.
• JIT access is independently approved, scope-frozen, time-bounded, auditable, and immediately revocable.
• Offboarding closes the implemented local relationship and active elevation paths; target assignments, external sessions, and secrets close only through conformant lifecycle adapters with matching read-back evidence.
• Every decision identifies the contributing contract, capsule, obligations, and policy version.
• Every target adapter proves semantic fidelity before apply and supports read-back, rollback, and drift response.
• Unknown datasets, owners, classifications, obligations, or bypass paths remain blocked until governed.
• Pagination, filtering, sorting, aggregates, charts, search, and export use the same server-side row and field policy; no operation materializes the complete store in the browser.
• The pilot passes functional, negative, failure, recovery, ≥100,000-row scale, concurrency, and independent security review.

4. Few-role RBAC + ABAC + ReBAC

Classic RBAC fails when a role name encodes job × tenant × vendor × company × region × application × fields. Five stable capability personas avoid that multiplication:

Current implementation and remaining gap: the seeded personas illustrate scope separation. Role Studio now content-addresses and reuses an action/ceiling capability persona, purpose/scope capsule, and matching contract; the principal assignment lives on the membership relationship. Identical drafts no longer create per-person copies. The authoring vocabulary can still form more combinations than the intended five governed capability personas, so production policy must constrain it to approved Viewer, Operator, Data Steward, Security Auditor, and Platform Admin templates plus shared typed scopes.

5. Contract Capsule and DataScope

A Contract Capsule is one atomic authorization envelope. Its row predicate and field release remain coupled; combining several grants must never create a wider row/column cross-product.

Representative DataScope

{
  tenant: "enterprise-a",
  products: ["process_chains", "bw_vendor"],
  companyCodes: ["1000"],
  purchasingOrganizations: ["US01", "US02"],
  plants: ["TX01"],
  classificationMax: "confidential"
}

“All view” is Viewer with an enterprise DataScope and appropriate class clearance, not Platform Admin. Restricted fields or export should be separate, justified, time-bounded actions.

6. Architecture: runtime today and production target

PurposeMesh’s target canonical model is application-agnostic: identity facts, business scope, policy, enforcement, and evidence stay separate so one access intent can govern a warehouse, SAP, search, BI, or a future application without copying the human role model into every platform. The running build is a reference estate with local enforcement and one minimal application decision adapter—not universal target enforcement.

How PurposeMesh knows the data—and who may access it

Access → Data runtime path

Capability boundary: the tool can decide access for data and identity metadata registered in PurposeMesh. The demo has one hard-coded data-owner reviewer in data-governance-owner and three fixed warehouse SoD rules; it does not crawl enterprise systems, discover schema or lineage, derive owners from a catalog, inspect target grants, infer entitlement from behavior, or synchronize HR/directory assignments. Production connectors may suggest classifications, but accountable owners approve them. Unknown or unclassified resources remain restricted; access is explicit policy, never an AI guess.

Governed standing-access path

The requester, target, and one person attempting both reviewer roles are rejected. The service proves that independent reviewers are available before accepting the request, rechecks reviewer authority and SoD before final application, and never treats the first approval or a UI-visible draft as access. Recertification later refers to the exact assignment id and captured membership fingerprint so review cannot drift onto a replacement membership.

Production target flow

Fidelity firewall

Each adapter declares exactly what it can enforce. A policy is deployable only when every mandatory property has a safe implementation:

The current compiler records required, supported, and missing local capabilities. It may still show a native-shaped preview when a gate fails, but missing purpose/row or other required fidelity marks deployment blocked, sets previewOnly, and keeps all execution-plan arrays empty. Its model is hard-coded, not discovered from an installed platform version. Only a future connector-executed apply followed by matching target read-back is enforcement evidence.

Current trust path

One contract, many enforcement points

Robustness: verified local recovery and production target

Current verified boundary: the single-node SQLite control snapshot can be copied with SQLite online-backup semantics, parsed through the production snapshot loader, and checked against a hash-and-count manifest. Restore revalidates the bundle, swaps it transactionally, and retains a rollback bundle; path-component checks reject symbolic links. This is local backup/restore, not offsite, encrypted, immutable, point-in-time, or regional disaster recovery.

Current evidence boundary: each audited mutation persists a complete JSON snapshot containing the growing audit array, so storage and write work grow with retained history (O(N) snapshot size). The local unkeyed hash chain can reveal inconsistent retained events, but a writer able to replace the complete mutable snapshot can truncate or recompute it. A colocated backup manifest proves bundle integrity, not external audit anchoring.

• Stateless API/PDP replicas across failure domains backed by a transactional policy store.
• Outbox-backed connector work so state change and delivery cannot diverge.
• Signed policy versions, an explicitly bounded last-known-good cache, and authorization epochs in cache keys.
• Fail closed for restricted reads, writes, export, JIT, and governance; no generic fail-open switch.
• External append-only audit with an independent anchor, target evidence, offsite/encrypted backup, point-in-time restore, key rotation, chaos, and regional recovery tests.

No unmeasured promise: this repository has one SQLite writer. Availability, revocation, and recovery SLAs must be measured with the real identity provider, data volume, network, and target platforms before they are claimed.

7. Current seeded personas and capsules

These identities make the local scenario demonstrable; they are not the recommended production role taxonomy. Production should map them to the five reusable Viewer / Operator / Data Steward / Security Auditor / Platform Admin capability personas plus shared scopes. Shared demo password: cca-demo.

Least-privilege pipeline stages

Each stage has a separate workload principal, capsule, contract set, and compiled SPIFFE-shaped desired identity. The replicator is explicitly denied provider write, so compromise of the first stage does not inherit the activation stage. These identities still use the shared password only as local fixtures; no SPIFFE credential is issued and no SAP, BW, ADF, or Elasticsearch target is changed. Parent capsule Vendor domain exists so local offboard can cascade ACME and Globex together.

8. Decision equation (deny by default)

Missing context is a denial. Clients cannot omit purpose, scope, or the record to widen a decision. The implemented check is:

Contract allow (data path)

1. Unknown, disabled, or time-invalid subject → deny.
2. Persona lacks the requested action → persona_lacks_verb.
3. Purpose missing or blank → purpose_required.
4. No active capsule membership → no_capsule_membership.
5. Binding must join a live capsule to a contract on that dataset; persona id (or inherits) must be allowed; contract must include the action.
6. Purpose must equal the contract purpose.
7. Record or dataset classification must be at or under the contract maximum and the persona ceiling. Ceiling none fails the data path.
8. If the predicate is not true, a record is required; the predicate is evaluated against record attributes and capsule attributes (eq, in, fromCapsuleAttr, and, or).
9. Every matching candidate is kept. Deny-fields are the union (conservative). A later valid contract cannot be hidden by an earlier miss.

Control-plane path

Datasets marked controlPlane (the audit log) require purpose governance, an action of audit, administer, or rotate, and membership in the control-plane capsule.

JIT fallback

JIT is evaluated only when no standing contract allows the request. It is not a dataset-wide bypass. A request must resolve a predeclared approvalRequired contract bound to the live capsule and allowed persona. The grant snapshots contract id, frozen predicate and capsule attributes, classification maximum, field allow/deny lists, actions, purpose, policy version, assurance context, and expiry. At use time the PDP rechecks live principal/capsule state, persona verb, exact resource/purpose/action, not-before/expiry, the frozen row predicate, and both persona and contract classification ceilings. Released fields are the dataset allowlist intersected with the JIT allowlist, minus JIT denies.

Approval is by a different control-plane Platform Admin and may not widen the requested envelope. The requester or a Platform Admin can revoke an approved grant with a reason; membership removal, capsule offboard, principal disablement, or expiry also closes it. Regression tests prove the frozen ACME vendor set never returns GLOBEX after live scope changes. There is no seeded restricted S/4 JIT template: an unconfigured request fails early, and even a test-injected restricted template fails because its dataset is above the L2 confidential ceiling.

9. Role Studio: rules, not an LLM

Role Studio turns a business need into a reviewable draft and then submits a governed standing-access request. Editing or previewing the draft never assigns access.

• Ask-to-role is a parser. parseNeedToRole matches phrases (process chain, BW vendor, BOBJ, ES logs, tenants, regions, “not vendor PII”, and so on). It is deterministic. There is no model call.
• Canvas is tokens. Verbs, purpose, ceiling, SAP and generic products, sources, tenants, regions, departments, and field masks. Click or drag onto wells. Validation is schema-bound to approved enumerations.
• Preview is metadata only. Impact totals run against the warehouse filter. Record samples are stripped from authoring preview so a draft cannot leak rows.
• Request-only apply path. POST /api/role-requests freezes the draft and review evidence. The legacy-looking POST /api/roles/apply route always returns approval_workflow_required; there is no direct assignment route.
• No membership back door. POST /api/capsules/:capsuleId/members and the core lifecycle reject every business/data capsule add with approval_workflow_required. Only explicit control-plane administrator recovery retains a direct add.
• Two independent approval roles. Every request requires one eligible data-owner approval and one eligible governance-admin approval from two different people. The requester and target cannot review the request, the same reviewer cannot satisfy both roles, and the request is rejected up front if an independent pair is unavailable.
• Partial approval grants nothing. The first decision is stored and shown as progress while the request remains unapplied. Before the second approval, the service revalidates reviewer authority, target state, frozen evidence, and separation-of-duty results; only then does internal applyRoleDraft content-address and reuse a capability persona, scoped capsule, and matching contract, store the assigned persona on a uniquely identified membership, and retire superseded Role Studio memberships.
• Separation of duty is executable. Versioned local rules evaluate standing plus candidate warehouse access and reject: operating both s4_master and transactions; combining purpose audit with operate; or combining purpose data-governance with operate.

Configuration boundary: the seeded Data Owner and those three SoD rules are intentionally hard-coded reference fixtures, not a generic ownership registry or policy administration engine. Production must constrain roles to approved capability templates, derive accountable owners from governed resource relationships, and manage organization-specific, versioned conflict rules.

Both authorship paths work in the demo: a non-reviewer self-request is approved by dana.owner plus either independent admin. If hugo.admin authors a cross-target request, Dana plus iris.admin must approve it because Hugo is ineligible to review his own request; the reverse applies when Iris authors. Both admins have control-plane membership and no business-data ceiling.

Example asks the parser is tested against:

• L1 support should see process chain health but not vendor PII
• ACME finance team only NA transactions
• observability can see ES/pipeline logs with payload stripped
• GLOBEX EU team needs BW vendor analytics and customer tickets, no bank accounts

Manual access recertification

A Governance Admin can start or renew a recertification campaign. The seeded Data Owner and Governance Admin can list evidence and decide only items for which their reviewer role is eligible: administrator access requires Data Owner review, Data Owner access requires Governance Admin review, and ordinary human access permits either. Each item captures the exact human membership assignment id plus principal, capsule, persona, and a fingerprint. Attest keeps that assignment; revoke removes that exact assignment and retains the last-admin safeguard. A reviewer cannot certify their own membership.

Current limitation: campaigns include active human memberships only. There is no scheduler, notification service, workload-membership review, or automatic overdue enforcement. Status is refreshed when a recertification endpoint is used; passing the due time marks a campaign expired but does not revoke its pending memberships.

10. Dataset, classification, catalog, and lineage

Reference data product: vendor process-chain runs

The safest monitoring product is curated separately from raw replication payload. Scope dimensions travel with every row; prohibited secrets are rejected before ingest.

Access matrix over the same source

How PurposeMesh learns what data exists

1. Connectors inventory systems, schemas, fields, BW objects, indexes, semantic models, dashboards, existing access, and direct-query paths.
2. Lineage links S/4 source → BW object/process chain → Elasticsearch, warehouse, or ADF destination → BI semantic model.
3. Rules and scanners propose classifications. Inferred labels remain candidates; automation never auto-grants.
4. The accountable owner confirms classification, permitted purposes, and scope dimensions.
5. The resource publishes only when required enforcement capabilities pass the fidelity firewall.
6. Schema, labels, lineage, ownership, and actual target grants are rescanned and reconciled.

Current answer: PurposeMesh only knows seeded/manually registered resources, fields, classifications, capsule attributes, and the demo’s hard-coded Data Owner relationship. It has a local two-role approval workflow, but no crawler, production catalog, classification scanner, lineage collector, generic resource-owner registry, or entitlement-discovery connector. Unknown/unclassified data must remain restricted until those governed inputs exist.

Local dataset used by the demo

The first API start builds one deterministic 100,000-row synthetic unified store at data/cca.sqlite. It is one physical fact store, not one copy per role. Each fact carries business-scope, source-pipeline, and classification dimensions. Queries compile product plus optional tenant, region, department, source/pipeline, and classification ceiling into parameterized SQL, then apply an explicit field allowlist and deny obligations before returning a bounded page.

Separate hand-authored core records cover SLA, process-chain status/detail, BW vendor, S/4 vendor master, BOBJ, and Elasticsearch examples. Those small records test individual PDP decisions; the unified store tests large row scopes, field projection, pagination, and role-to-role isolation.

Desired state lives in data/cca-control.sqlite as a single snapshot. Demo/test startup may migrate v2→v3 only when legacy JIT is empty and every membership persona resolves from validated principal data; the migration is audited. Production refuses automatic v2 migration and requires a reviewed offline procedure. This remains a one-node demonstration persistence boundary, not an enterprise catalog or multi-replica policy database.

11. Authentication, JIT, onboarding, and offboarding

Authentication is not authorization

Current local authentication: demo mode exposes a seeded directory and scrypt password login. The demo JWT is short lived. Production mode disables those routes and validates a strict HS256 token contract intended for an upstream broker, with issuer, audience, subject, expiry, issued-at, token id, purpose, bounded lifetime, authentication assurance (password, mfa, or phishing-resistant), a required 64-hex authorization fingerprint, and current persona/kind checks. The fingerprint covers exact live membership assignment ids, personas, and capsules and is recomputed on every protected request; removal invalidates the token, and same-capsule re-grant cannot revive it. JIT assurance is copied from that verified token, never trusted from the request body; the upstream issuer remains responsible for actually establishing MFA. The web app stores its bearer token in tab-scoped sessionStorage, removes legacy localStorage, warns shortly before expiry, and clears protected state on expiry, 401, or account switch.

Not implemented: enterprise OIDC authorization flow, SCIM/HR sync, WebAuthn/conditional access, DPoP or mTLS token binding, cloud managed identity, SPIFFE issuance, certificate rotation, or lifecycle connectors. The API sets cache, MIME, and referrer hardening headers and the local HTML installs a baseline document-level CSP, but JavaScript can still read the current bearer token and production still needs a tested response-header CSP. The compiler’s SPIFFE string is desired state, not workload authentication.

Production target: OIDC/BFF with Authorization Code + PKCE, exact redirects, phishing-resistant MFA and step-up for privileged actions, and an HttpOnly, Secure, appropriately SameSite session cookie with CSRF protection and a restrictive tested CSP; unique short-lived managed/SPIFFE identities for pipelines; narrow vaulted SAP communication identities only where legacy integration requires them.

JIT is a bounded policy snapshot—not a bypass

• The request resolves exactly one predeclared approvalRequired contract bound to the active capsule and permitted persona.
• The grant snapshots contract id, frozen predicate and capsule attributes, classification maximum, allow/deny fields, actions, purpose, policy version, server-derived token assurance, and expiry.
• A different active control-plane Platform Admin approves; approval cannot widen rows, class, fields, actions, purpose, assurance, or duration.
• Each use re-evaluates live identity/membership, persona action, resource/purpose, time, frozen row predicate, persona ceiling, contract ceiling, and field intersection.
• Requester or Platform Admin can revoke with reason; disablement, membership removal, capsule offboard, or expiry also closes the online grant.

Required regression: an ACME-scoped L2 JIT grant returns only the frozen ACME vendor set, never GLOBEX, even if live capsule attributes later change. Restricted S/4 JIT is rejected before approval when no eligible template exists or the requester ceiling is too low. The same invariant must hold in the PDP, API, SQL path, and each target adapter.

Smooth onboarding

Current periodic review boundary

Manual recertification snapshots active human assignments by assignment id and membership fingerprint, accepts attest or exact-assignment revoke decisions from an eligible non-self reviewer, and preserves the last control-plane admin. It does not schedule campaigns, notify reviewers, include workload memberships, or revoke access merely because an undecided item is overdue.

One offboard intent; external proof required

PurposeMesh records one central lifecycle intent. The current build revokes locally governed access; enterprise completion requires conformant adapters with published evidence to execute and verify the target-specific steps below.

1. Mark team/capsule inactive so online decisions deny.
2. Revoke sessions/refresh and update the authorization epoch.
3. Remove memberships, bindings, JIT, and expiring access leases.
4. Disable or transfer team-owned workload identities and secrets.
5. Apply removal to every target, read it back, and prove zero residual grants.
6. Retain correlated, immutable completion evidence.

Current local behavior: a control-plane admin can deactivate one capsule or descendants, remove local memberships/bindings, expire local JIT, and receive pre-removal compiler previews. The control-plane capsule and last-admin safeguards remain. Because fidelity is blocked, the execution/revoke plan is empty; nothing is sent to SAP or Elasticsearch, and the repository cannot yet prove external removal.

12. Threat model and platform enforcement points

Priority threats

Native enforcement map

BI rule: prefer live connection plus store/semantic-model security. Any extract or import is data movement and becomes a new governed resource. No BI adapter exists in this repository.

13. AuthZEN, compiler outputs, and fidelity

Application interoperability: minimal adapter now, broader target next

The current API exposes POST /access/v1/evaluation using the OpenID Authorization API shape: subject, action, resource, and context. It accepts a user/workload subject, a canonical action, a dataset, trusted purpose, and optional recordId. A normal caller can evaluate only the authenticated subject and its purpose must exactly match a scoped token. Cross-subject checks require a Platform Admin; a scoped admin token must be governance-scoped. Records are resolved server side, unknown or mismatched resources deny, and every evaluation is audited.

{
  subject: { type: "user", id: "emma.acme" },
  action: { name: "view" },
  resource: { type: "dataset", id: "bw_vendor" },
  context: { purpose: "vendor-performance", recordId: "bw-1" }
}

The response returns decision plus reason and obligations: allowed/denied fields, matching contract ids, capsule ids, and JIT policy version when applicable. The application PEP must apply every obligation before data release.

Boundary: this is a strict minimal reference adapter, not a claim of ecosystem-wide conformance. General resource types, richer DataScope and mask/no-export/maximum-row obligations, batch/search evaluation, PEP SDKs, conformance suites, and enterprise identity remain target work.

Desired-state compiler now

Admin routes GET /api/compiler and GET /api/compiler/:capsuleId return local JSON. Every capsule result has a deterministic policyHash and policyVersion, only active persona-compatible assignments, a deploymentStatus, previewOnly, target capability gates, and target-shaped artifacts. Required purpose/row fidelity is not available in current target compilers, so seeded target-bearing policies are blocked and their apply/revoke/read-back arrays are empty. No external target adapter or connector is present.

Current compilation fails closed on unsafe predicate material and on locally known missing capabilities. It does not yet publish a discovered, version-scoped capability manifest with passing conformance evidence for every target or implement native masking, general SAP dimensions, purpose/JIT delivery, connector apply, rollback, executed read-back, drift, or target audit.

Adapter definition of done

1. Declare exact platform version/edition and capability manifest.
2. Produce deterministic plan and diff from one signed policy version.
3. Apply and revoke idempotently with bounded retry and rollback.
4. Read target state back; do not mark active/revoked until it matches.
5. Continuously detect drift and quarantine unsafe targets.
6. Run differential tests proving the target returns exactly what the canonical PDP returns for the same subjects and data.

14. Run the demo and interpret verification

Requires Node.js 24+ and npm 11+.

1. From the repository root: npm install
2. Run npm run preflight for repository typechecks, core/API/web tests, and production builds.
3. Run npm audit --omit=dev --audit-level=high for the dependency gate.
4. npm run dev builds @cca/core and starts API + Vite console. API dev sets CCA_MODE=demo.

Suggested walkthrough

1. If this checkout preserved a v2 demo snapshot, sign in as hugo.admin, open Lifecycle, choose Reset demo, and confirm RESET once to load the expanded v3 S/4→BW→ES fixtures. This replaces local demo policy and audit state and is unavailable in production.
2. Sign in as dana.owner (Data Owner, capsule data-governance-owner). Open Access → Data and select Run authorized view.
3. Run the view. Confirm the title changes to …’s authorized records, the default store reports 100,000 synthetic facts, the complete explicit warehouse field allowlist is returned through wh.data-owner, the ceiling is Restricted, and Why this view is allowed identifies purpose data-governance. This is the controlled source baseline.
4. Select Switch account. Verify the old token, rows, counts, fields, receipt, and in-flight requests are cleared. Sign in as emma.acme, return to #/data, and run again. Confirm only ACME rows and her approved fields arrive over the network.
5. Repeat with finn.globex; confirm every returned row is GLOBEX and no ACME value is present. Repeat with gita.steward; confirm steward capabilities do not broaden the assigned tenant.
6. Repeat with ana.l1, ben.l2bw, cara.l2bobj, and dev.obs. For each identity, compare Protected fields, row scope, products, classification ceiling, source/pipeline lineage, and the Authorization receipt against the matrix below.
7. Finally use both hugo.admin and iris.admin. Confirm each Platform Admin can operate governance views but receives zero business rows and cannot obtain the Data Owner baseline by changing purpose, filters, route parameters, or client state.
8. Sign in as a non-reviewer test identity such as ana.l1, open Request a role, and ask: L1 support should see process chain health but not vendor PII. Generate, tweak, preview, and submit the frozen self-request. Confirm no access changes on submission.
9. Sign in as dana.owner, open Access Reviews, and approve as Data Owner. Confirm the request shows one of two approvals and remains unapplied. Then sign in as hugo.admin and approve as Governance Admin. Only now confirm that the reusable persona, capsule, warehouse contract, and uniquely identified membership appear.
10. Test the cross-target path separately: sign in as hugo.admin, open Role Studio, author and submit a request for a non-admin target, and confirm no access changes. Approve it first as dana.owner, then as iris.admin. Confirm Hugo cannot approve the request he authored and final application occurs only after Iris supplies the independent Governance Admin approval.
11. Open Policy compiler. Inspect JSON for Vendor ACME (ES terms on vendor_id, BW 0VENDOR, no live deploy banner).
12. Capsule lifecycle: offboard Vendor ACME. Emma loses the slice; Finn does not.
13. JIT: request from a non-admin against a predeclared bound contract. Approve only as Hugo, verify the row scope is unchanged, then revoke as requester or admin with a reason.

Role-by-role acceptance matrix

Field-policy caution: the matrix above states the seeded contracts exactly. It is not a declaration that every other synthetic field is safe in production. Before using real data, accountable owners must classify fields such as email, vendor identity, legal name, bank data, tax identifiers, and payload, then tighten each contract allowlist accordingly.

Network-level proof: inspect API responses, not only rendered columns. A test fails if an unauthorized value reaches browser memory and is then hidden by React or CSS. Each role test must also cover direct record lookup, crafted tenant/product/pipeline filters, purpose mismatch, sort/search/aggregate/export paths, rapid account switching, offboarding, JIT expiry, and a newly added database column.

Security, failure, and scale gates

What the automated evidence means

The local suites cover policy, API, web, login-to-policy, JIT lifecycle, persistence, and build behavior. They can prove only the code paths and fixtures they execute. They do not exercise a real SAP authorization object, BW analysis authorization, Elasticsearch role, ADF identity, warehouse-native RLS, or BI semantic model. Those claims require target-specific conformance environments and differential tests.

Latest full gate · 16 August 2026: repository typechecks and production builds passed; 57 core + 84 API + 55 web tests passed (196 total). There were no known vulnerabilities reported by npm audit on 16 August 2026 in the complete and production-only dependency scans. This is point-in-time dependency evidence, not proof that the application or future integrations are vulnerability-free.

15. Current implementation versus production target

Robustness claim: local tests demonstrate the local implementation. The current full-snapshot persistence path grows with retained audit history, and its mutable local hash chain is not an external anchor. Production robustness begins only when every real access path and target has a documented passing conformance result, is continuously reconciled and failure-tested, and has undergone independent security review.

16. Now / Next / Later delivery roadmap

Roadmap state changes only when linked tests and public evidence satisfy the exit gate. Dates are planning windows, not production commitments; stars and page views measure awareness, not authorization correctness or adoption.

Metric definitions: a successful external evaluation means a non-maintainer starts the project, compares at least two personas against the same synthetic store, confirms row/field isolation, and records the outcome. A pilot means a named owner evaluates a non-demo target with an agreed access boundary and success criterion. A target is “verified” only for the documented version, edition, configuration, and access paths that passed the conformance gate; this is project test evidence, not independent certification.

After the first 90 days

1. Identity and catalog. Complete enterprise OIDC/SCIM, workload identity, governed inventory, owner, classification, schema, lineage, and existing-access ingestion.
2. One complete enterprise path. Prove S/4 → BW process-chain/vendor monitoring → governed target store → one BI model, with Vendor Ops, L2, Platform Ops, and JIT Audit.
3. Expand one target at a time. Add SAP/BW, ADF, and BI only after the adapter SDK and fidelity gate work on PostgreSQL and Elasticsearch. Do not count a generated policy document as an integration.
4. Enterprise hardening. Add multi-replica state, outbox workers, immutable audit, performance budgets, recovery, chaos, independent threat review, and red-team testing.

Differentiation, stated honestly: the individual controls are established patterns. The product thesis is that a portable atomic access capsule, lineage-aware policy delivery, a fidelity firewall that refuses unsafe translations, access leases, and continuous target-state proof can reduce authorization drift across mixed estates. External adapters, independent contributors, and adopters—not a novelty claim—must validate that thesis.

Primary standards and platform documentation

• NIST RBAC model
• NIST ABAC SP 800-162
• NIST Zero Trust SP 800-207
• NIST SP 800-53 Rev. 5, including Update 1
• OpenID Authorization API 1.0
• PostgreSQL row security policies
• Open Policy Agent documentation
• Cedar policy language documentation
• OpenFGA authorization model
• SpiceDB relationships
• Cerbos documentation
• OWASP Session Management Cheat Sheet
• OWASP Content Security Policy Cheat Sheet
• OAuth Security BCP — RFC 9700
• SCIM Protocol — RFC 7644
• SPIFFE workload identity
• SAP BW authorization concepts
• SAP process-chain authorizations
• Elastic DLS/FLS and limitations
• Azure Data Factory security
• Power BI consumer security