Skip to content

Platform Tenant / Capability — Dual-Ref Current Authority — 2026-08-09

  • Status: CURRENT DUAL-REF SOURCE AUTHORITY / DOCUMENTATION ONLY
  • Release documentation ref: master@9d285d34488aa0554ed56a721dbda4ff60c10ae0
  • Release source authority: master@baff406d964b9f785bf98d2ae84cfb262e26f4b2
  • QA documentation ref: qa@4f8a9c2ff4d6ed9aab5e5f4b8593574de3bc7c83
  • QA integration source authority: qa@1dfed7d5c827f992e763c63bfca95324a60af387
  • Original deferred candidate: codex/p4@db306fbb5b698daf92e88ab0db70f0c22c4e8ea2
  • Parent platform authority: PLATFORM_TENANT_PROFILE_CAPABILITY_CONFIGURATION_SOURCE_AUTHORITY.md
  • Parent rebuild packet: PLATFORM_TENANT_PROFILE_CAPABILITY_CONFIGURATION_REBUILD_PACKET.md
  • Delta matrix: PLATFORM_TENANT_CAPABILITY_RELEASE_QA_DELTA_MATRIX_2026-08-09.md
  • Evidence addendum: RBR-TENANT-CAPABILITY-002-READONLY-DUAL-REF-PREFLIGHT.md
  • Phase implementation: USER HOLD
  • Runtime, DB, role, menu, module, config, credential, provider, Wiki, deployment and Production effects: NONE

1. Purpose

The platform reconstruction packet already establishes the semantic separation:

Tenant Identity
!= Operating Profile
!= Module Enablement
!= Named Process Capability
!= Package / Entitlement
!= Typed Configuration
!= Credential Availability
!= Menu / Page / API / Action / Record Authorization

A later source candidate added a typed definition registry and effective capability diagnostics. The historical handoff recorded that candidate as deferred and absent from current qa.

That branch-status statement is no longer current.

codex/p4@db306f...
-> is now an ancestor of current QA source
-> is still absent from release master source

This document fixes that branch authority without merging QA Runtime into Release or treating QA-only diagnostics as a universally released platform capability.

2. Current Branch Authority

2.1 Release

master source authority = baff406...

Release contains the earlier typed foundations:

  • TenantExecutionContext and selected strict-principal adapters;
  • CapabilityResolution;
  • CapabilityResolver;
  • legacy page/module/config resolution;
  • tenant provider/config helpers;
  • current Admin Console local applied-state editing.

Release does not contain the QA-only source listed below:

CapabilityDefinitionRegistry.php
effective_capability_diagnostics.php
GET /api/platform/admin/tenants/{clientId}/effective-capabilities
Admin Console Effective diagnostics view
moduleGuardStrictModuleDecision() registry integration

Therefore the release environment must not be documented as exposing effective capability diagnostics unless an exact deployed SHA proves otherwise.

2.2 QA integration

qa source authority = 1dfed7...

QA contains the original candidate source and later integration changes. The candidate registry and diagnostics files are unchanged from db306f... to the reviewed QA source for their core blobs.

QA adds:

  • a registered definition adapter for module, process-capability, config and secret concerns;
  • typed config observation and validity handling;
  • strict API module resolution through the existing CapabilityResolver;
  • a safe effective-state diagnostics endpoint;
  • an Admin Console diagnostics projection;
  • provider/config metadata registration;
  • selected cache-key changes;
  • focused source-level contract tests.

QA is not a complete platform-policy cutover.

QA typed strict API path
+ legacy non-strict page/API path
= hybrid current integration authority

3. Candidate Status Correction

Historical source-candidate handoff:

docs/operations/changes/
2026-08-07-p4-capability-diagnostics-source-candidate-handoff.md

That document remains valid as a historical record of the decision made on 2026-08-07. Its current-branch statement is superseded as follows:

Question Historical result Current result
Candidate source preserved yes yes
Candidate merged into release master no no
Candidate present in current QA lineage no at the time yes
P4 Phase activated no no
DB parity seed performed no not established
Live Client 1/2 acceptance no not established
Production deployment proven no not established

Stable discrepancy:

CAPABILITY-DISCREPANCY-001
Historical handoff says the candidate is not current QA.
Current QA contains the candidate as an ancestor.
Disposition: HISTORICAL STATUS SUPERSEDED BY THIS DUAL-REF AUTHORITY.

4. Current QA Definition Registry

CapabilityDefinitionRegistry adapts current metadata into the existing resolver definition schema.

Registered concern families:

MODULE_ENABLEMENT
PROCESS_CAPABILITY
CONFIG_VALUE
SECRET

Supported typed values include:

string
bool
int
url
uuid
datetime
json
file_id
secret

The registry is an adapter and definition boundary. It is not, by itself:

  • a tenant profile store;
  • an entitlement authority;
  • a role or command authorization engine;
  • a provider-effect permission service;
  • a hardware adapter registry;
  • a release/publish/apply control plane;
  • proof that all Runtime callers use the typed result.

4.1 Module definitions

QA strict module definitions can preserve current compatibility behavior:

explicit enabled  -> ENABLED
explicit disabled -> DISABLED
missing row       -> ENABLED / compatibility fallback
source error      -> ENABLED / compatibility fallback

This is diagnostic provenance around current behavior, not a fail-closed conversion.

4.2 Process capability definitions

QA currently registers a bounded subset, including:

MK_DOCUMENT_WORKFLOW_ENABLED
EXPORT_BROKERAGE_WORKFLOW_ENABLED

The registered defaults are compatibility defaults:

MK document workflow
-> legacy default depends on numeric tenant compatibility
-> Client 2 default-on when the explicit row is absent

Export Brokerage workflow
-> legacy default false

A compatibility default is not an explicit tenant policy or accepted entitlement.

Stable discrepancy:

CAPABILITY-DISCREPANCY-004
Registered process capability can resolve from LEGACY_DEFAULT.
Disposition: DIAGNOSTIC COMPATIBILITY, NOT EXPLICIT PRODUCT POLICY.

4.3 Configuration and secret definitions

QA definitions preserve:

  • owning module key;
  • expected value type;
  • allowed source family;
  • validity;
  • compatibility/default source;
  • provider label where registered;
  • credential-owner metadata for safe secret resolution.

Secret diagnostics do not return the credential literal through CapabilityResolution::toSafeArray().

secret configured metadata
!= secret value disclosure
!= provider connectivity
!= provider permission

5. QA Effective Diagnostics

QA exposes a read-only effective-state projection with schema:

tenant-effective-capabilities/v1

It reads:

  • active module catalog rows;
  • tenant-module assignments;
  • registered process-capability/config/secret definitions;
  • safe config presence/type metadata;
  • module tier values;
  • optional package-tier catalog state.

It returns:

tenant identity state
relationship summary
module resolutions
registered process-capability resolutions
registered configuration resolutions
compatibility fallback count
invalid/error count
explicit limitations

5.1 Correct interpretation

The current diagnostics explicitly report unresolved platform concepts rather than fabricating them.

Concern QA diagnostics disposition
Tenant identity local legacy identity
Profile UNBOUND
Package absent, legacy-derived from one tier, or invalid when tiers conflict
Module resolved per module
Capability registered subset only
Entitlement UNKNOWN
Role/Menu external authority
Terminology UNBOUND
Document template UNBOUND
Provider registered config subset; effect authority unknown
Hardware UNBOUND

5.2 Non-implications

Effective diagnostics available
!= P4 accepted

Module ENABLED
!= named process capability enabled

Capability ENABLED
!= actor authorized

Config VALUE
!= provider effect authorized

Secret hasValue
!= provider connectivity verified

Package LEGACY_DERIVED
!= commercial entitlement

QA endpoint success
!= release endpoint exists

Stable discrepancy:

CAPABILITY-DISCREPANCY-005
Effective endpoint and UI exist on QA but not release master.
Disposition: QA INTEGRATION-CANDIDATE SURFACE ONLY.

6. Hybrid Resolver Boundary

6.1 QA strict API path

QA moduleGuardStrictModuleDecision() uses:

strict TenantExecutionContext
-> T_TENANT_MODULE observation
-> CapabilityDefinitionRegistry::module(..., compatibility=true)
-> CapabilityResolver
-> safe resolution

This path preserves explicit-disabled behavior and exposes missing/error fallback provenance.

6.2 QA non-strict path

Current page and non-strict route behavior still uses the legacy module/config decisions.

moduleGuardModuleDecision()
moduleGuardPageDecision()
moduleGuardConfigDecision()
isModuleEnabled()
tenant_config_get_bool()

The typed resolver has not replaced these authorities across all callers.

Stable discrepancy:

CAPABILITY-DISCREPANCY-002
QA has typed strict API resolution and legacy non-strict resolution concurrently.
Disposition: HYBRID INTEGRATION; CALLER INVENTORY AND PARITY REQUIRED.

6.3 Migration constraint

A future cutover must operate caller by caller.

read shadow
-> exact parity
-> selected caller authoritative cutover
-> rollback
-> legacy caller-zero

Do not globally change missing/error behavior from the diagnostics work.

7. Cache Scope Discrepancy

The QA single-value config reader keys its static cache with the DB object identity:

spl_object_id($db) + clientId + configKey

The QA multi-value reader still keys its cache by:

clientId + configKey

Therefore the broad historical claim that tenant config caches are fully partitioned by DB identity/object is too strong.

Stable discrepancy:

CAPABILITY-DISCREPANCY-003
single-key cache = DB-object scoped
multi-key cache  = not DB-object scoped
Disposition: PARTIAL CACHE ISOLATION / SYNTHETIC MULTI-DB EVIDENCE REQUIRED.

Potential impact is bounded but material for:

  • local/test processes that use more than one DB object in one PHP process;
  • diagnostic readback against multiple databases;
  • long-running CLI or test processes;
  • provider config reads through tenant_provider_config().

This document does not claim a Production incident. Ordinary short-lived web requests may not reproduce the condition.

8. Release / QA Comparison

Surface Release master QA integration
CapabilityResolver foundation present present
CapabilityDefinitionRegistry absent present
Effective diagnostics service absent present
Effective diagnostics API absent present
Admin Effective projection absent present
Typed strict module decision absent present
Legacy page/module decision present present
Missing module compatibility present present, with typed provenance on strict path
Profile binding absent absent / reported unbound
Entitlement source absent absent / reported unknown
Role/menu authorization existing external owner existing external owner
Process capability registry absent registered subset
Full caller cutover no no
Current environment acceptance not established not established

9. Access And Security Boundary

The effective diagnostics endpoint reuses current Admin Console tenant-config access behavior.

Required current evidence:

  • super-admin explicit target-tenant access;
  • tenant administrator same-tenant restriction;
  • denial for another tenant;
  • direct and impersonated Actor/Subject behavior;
  • no secret literals in response or rendered UI;
  • no config/module write on GET;
  • no broad provider or customer payload;
  • no cache of sensitive response;
  • no use of diagnostics as action authorization.

The endpoint is read-only. Its existence does not authorize module/config/credential changes.

10. Rebuild And Migration Implications

The QA work is useful implementation input for the approved long-term React + Next.js + TypeScript direction, but the current PHP source must not be copied as one universal policy module.

Target ownership remains:

TypeScript Tenant Context
-> Module Resolution
-> Named Capability Resolution
-> Typed Config Resolution
-> Credential Availability
-> Access Decision
-> Business Command

Each result remains separate.

Required migration constraints:

  1. pin exact release and QA source identities;
  2. enumerate every strict and non-strict caller;
  3. record explicit/missing/error behavior for Client 1 and Client 2;
  4. resolve cache scope before using diagnostics across multiple DB objects;
  5. seed explicit parity only under separate DB-write authorization;
  6. keep Role/Menu/Action/Record ownership external to capability diagnostics;
  7. cut over one caller/cohort at a time;
  8. preserve rollback and old-reader compatibility;
  9. prove caller-zero before retiring the legacy path;
  10. keep PostgreSQL work after React/Next.js/MySQL stabilization.

11. Evidence Required

Primary package:

RBR-TENANT-CAPABILITY-002

Required evidence families:

SRC branch/source/caller inventory
SCH module/config/package schema
DAT tenant module/config/tier state
ROL admin and denied-role access
RUN GET diagnostics and no-mutation behavior
SEC secret redaction and tenant boundary
CACHE single/multi DB-object isolation
WIK current restricted support content
DEP exact deployed release identity
MIG read parity, selected cutover, rollback and caller-zero

Current state:

static source reconciliation: COMPLETE
read-only package: DEFINED
DB/environment/browser evidence: NOT RUN
policy acceptance: OPEN / PARTIAL
M3: NO
M4: NO
Phase progress: NONE

12. Supersession And Preservation

The following remain valid historical/source inputs:

  • P4-003.md candidate chronology;
  • the 2026-08-07 deferred-candidate handoff;
  • the original platform tenant/capability reconstruction packet;
  • the original capability resolver foundation.

Current branch-status claims use this document.

historical deferred candidate
!= current QA lineage status

QA lineage status
!= released master behavior

released master behavior
!= deployed Production without readback

13. Effects Not Performed

Runtime source modification
DB connection/query/change
module/config/capability/credential change
provider call or connectivity check
role/menu/account change
Admin Console action
Wiki read/publication
service/deployment/recovery action
Phase activation

14. Current Conclusion

Candidate ancestry on QA:
CONFIRMED

Candidate presence on release master:
NO

QA registry/effective diagnostics:
SOURCE PRESENT

Release registry/effective diagnostics:
SOURCE ABSENT

QA universal resolver cutover:
NO

QA cache isolation:
PARTIAL

Profile/entitlement binding:
NOT ESTABLISHED

Environment/role/DB acceptance:
NOT RUN

M3/M4:
NO CHANGE

---

Source: docs/reconstruction/PLATFORM_TENANT_CAPABILITY_DUAL_REF_CURRENT_AUTHORITY_2026-08-09.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.