Skip to content

This is an internal working record, not an everyday instruction. It was written while the system was being rebuilt, for whoever maintains it. If you are here to do today's work, use the everyday documents instead: Procedures · Processes · Runbooks · The working day, step by step

Platform Tenant / Capability — Dual-Ref Operator Addendum

  • Status: CURRENT ADMIN/SUPPORT ADDENDUM / NO CHANGE AUTHORIZED
  • Current authority: PLATFORM_TENANT_CAPABILITY_DUAL_REF_CURRENT_AUTHORITY_2026-08-09.md
  • Evidence package: RBR-TENANT-CAPABILITY-002-READONLY-DUAL-REF-PREFLIGHT.md
  • Parent Runbook: PLATFORM_TENANT_CONFIGURATION_ADMIN_SUPPORT_RUNBOOK.md
  • Phase implementation: USER HOLD

1. Purpose

Use this addendum when diagnosing module, process-capability, package-tier, config or provider behavior after the QA capability-diagnostics source entered the QA lineage.

The first question is not “what setting should be changed?”

Which source lane is actually running?

2. Source Lane Classification

Record one result before interpreting any diagnostics.

RELEASE
= source equivalent to master@baff406...

QA INTEGRATION
= source equivalent to qa@1dfed7...

MIXED
= PHP, browser assets, services or databases do not share one release identity

UNKNOWN
= deployed identity cannot be proven

Release expectation

Release does not expose the QA effective-capabilities endpoint or Effective diagnostics view.

Do not report their absence as a Release defect.

QA expectation

QA contains the registry, strict module-resolution adapter and effective diagnostics projection.

Do not report their presence as a released or Production capability.

Stop

Stop diagnosis when the source lane is mixed or unknown. Do not compensate by changing module/config rows.

3. Current Authority Separation

Effective diagnostics
= safe read projection

Effective diagnostics
!= module/config writer
!= role/menu/access authority
!= process command authority
!= entitlement authority
!= provider connectivity test
!= Control Tower release state

Each current result must retain its owner:

Result Owner
Tenant identity Tenant context/session/deployment mapping
Module T_MODULE + T_TENANT_MODULE + current module guard
Process capability registered config subset or current legacy caller
Config value tenant config/current fallback owner
Credential availability credential owner and safe metadata
Role/Menu/Page/API existing access owners
Record eligibility business application owner
Provider effect provider-specific command and evidence
Package/Entitlement not established as one current authority

4. Release Diagnosis Procedure

  1. Confirm Release source/deployed SHA.
  2. Inspect current tenant, module, config and provider metadata through the existing Admin Console read surfaces.
  3. Build the page/API/action/record access row separately.
  4. Record explicit/missing/error compatibility from current helpers and DB metadata.
  5. Do not look for the QA-only Effective view.
  6. Do not describe profile, package or entitlement as resolved.
  7. Do not use QA screenshots or response shapes as Release instructions.

Release result vocabulary:

EXPLICIT MODULE STATE
MISSING-ROW COMPATIBILITY
CURRENT CONFIG VALUE/FALLBACK
CURRENT CREDENTIAL METADATA
PROFILE UNKNOWN/UNBOUND
ENTITLEMENT UNKNOWN
QA DIAGNOSTICS NOT RELEASED

5. QA Diagnosis Procedure

  1. Confirm QA integration source/deployed SHA.
  2. Record Actor, Subject and target Tenant.
  3. Open the approved Admin Console read surface.
  4. Use the Effective diagnostics GET only when specifically authorized.
  5. Record safe result fields:
  6. decision;
  7. source;
  8. validity;
  9. policy state;
  10. compatibility fallback;
  11. reason;
  12. hasValue;
  13. safe credential-owner metadata.
  14. Compare the typed strict-path result to the current non-strict page/API result.
  15. Record Role/Menu/Action/Record decisions separately.
  16. Confirm no rows changed and no provider request occurred.

Never record a secret literal.

6. How To Read QA Results

Module

ENABLED + TENANT_MODULE + VALID
= explicit enabled row

DISABLED + TENANT_MODULE + VALID
= explicit disabled row

ENABLED + NONE + MISSING + compatibilityFallback=true
= missing-row compatibility, not explicit enablement

ENABLED + NONE + ERROR + compatibilityFallback=true
= source-error compatibility, not healthy state

Process capability

ENABLED/DISABLED + TENANT_CONFIG
= explicit row result

ENABLED + LEGACY_DEFAULT
= compatibility default, not explicit tenant policy

DISABLED + NONE/MISSING
= missing and no enabled default

Config

VALUE + TENANT_CONFIG + VALID
= typed current value

VALUE + LEGACY_DEFAULT/CALLER_DEFAULT
= fallback value; source row not established

UNAVAILABLE + INVALID
= row/type/value conflict

UNAVAILABLE + ERROR
= source read error

Secret

hasValue=true
= a safe secret presence result with matching owner metadata

hasValue=true
!= secret shown
!= provider reachable
!= provider authenticated
!= provider effect permitted

Relationship

profile UNBOUND
= no current canonical binding

package LEGACY_DERIVED
= one observed module tier, not entitlement

package INVALID
= conflicting tier hints

entitlement UNKNOWN
= do not infer from package/module/role/config

7. Known Current Discrepancies

CAPABILITY-DISCREPANCY-001

Historical candidate handoff says the candidate is absent from QA. It is now a QA ancestor.

Operator action:

use current dual-ref authority
preserve historical handoff as chronology

CAPABILITY-DISCREPANCY-002

QA strict API and non-strict page/API paths use different resolution surfaces.

Operator action:

compare both paths
never infer global cutover from one strict route

CAPABILITY-DISCREPANCY-003

QA single-key config cache is DB-object scoped; multi-key config cache is not.

Operator action:

avoid multi-database conclusions in one long-lived process
use separately approved synthetic evidence

CAPABILITY-DISCREPANCY-004

Process capabilities can resolve from legacy defaults.

Operator action:

label COMPATIBILITY DEFAULT
never label EXPLICIT TENANT POLICY

CAPABILITY-DISCREPANCY-005

Effective diagnostics is QA-only.

Operator action:

show source-lane badge
never publish as Release procedure

8. Common Incidents

Effective endpoint returns 404

  1. Confirm deployed SHA.
  2. If Release lane, classify as expected absence.
  3. If QA lane, verify route/source deployment and PHP cache.
  4. Do not change module/config state.

QA Effective view shows many fallback items

  1. Distinguish missing rows from source errors.
  2. Identify current callers affected.
  3. Do not seed rows during diagnosis.
  4. Prepare a separate parity-seed proposal with rollback.

Explicit module says disabled but a page still opens

  1. Compare page registry, static page map and current page guard.
  2. Check direct URL, alias and super-admin/impersonation state.
  3. Compare non-strict and strict routes.
  4. Do not add a broad guard during diagnosis.

Module is enabled but an action is forbidden

Expected possibility:

module enabled
!= role/action/record authorized

Read Role/Menu/API/Record/State owners.

Process capability appears enabled from legacy default

  1. Record source=LEGACY_DEFAULT.
  2. Check whether an explicit row exists.
  3. Check numeric tenant compatibility.
  4. Do not describe it as package entitlement.

Package shows invalid

  1. Read module tier distribution.
  2. Check whether several active module rows use different tier values.
  3. Do not choose one tier automatically.
  4. Escalate to Product/platform owner.

Config readback differs across diagnostic tools

  1. Record DB object/process identity.
  2. Determine whether caller uses single-key or multi-key config read.
  3. Stop repeated read/write attempts.
  4. Use a synthetic multi-DB cache test only after authorization.

Secret appears in output, logs or screenshot

  1. Stop collection immediately.
  2. Restrict the evidence artifact.
  3. Treat as a security incident under the current incident process.
  4. Do not copy the value into tickets or documentation.
  5. Rotate only through separately authorized credential procedure.

9. Prohibited Fixes

  • enabling all missing modules;
  • changing missing/error behavior globally;
  • copying Client 1 role IDs to Client 2;
  • copying Client 2 numeric defaults to other tenants;
  • using module tier as entitlement;
  • adding another customer-specific branch;
  • changing Role/Menu state to make diagnostics easier;
  • revealing credentials to test diagnostics;
  • calling providers to prove a config value;
  • promoting QA source as part of a documentation task;
  • removing legacy callers before parity/rollback/caller-zero;
  • treating the Effective endpoint as command authorization.

10. Safe Escalation Packet

date/time/timezone
source lane and deployed SHA
PHP/browser/service identity
DB identity
Actor/Subject/Tenant
module/capability/config key
safe typed resolution
legacy current decision
page/API/action/record result
explicit row or missing/error path
role/menu result
package tier hints
secret configured boolean only
request/correlation ID
cache reader type: single or many
mutation observed: yes/no
provider effect observed: yes/no
known discrepancy ID
recommended next owner

Exclude values, tokens, credentials, customer payload and broad user data.

11. Promotion Readiness

QA diagnostics are not ready for release solely because source exists.

Required before a bounded promotion decision:

Client 1 explicit/missing/error parity
Client 2 expected parity
same-tenant/cross-tenant admin evidence
secret redaction evidence
strict/non-strict caller map
cache isolation disposition
no-mutation GET evidence
rollback
selected caller scope
observation owner

Promotion remains a separate source decision.

12. Current State

Release procedure:
LEGACY CURRENT PATH

QA procedure:
HYBRID DIAGNOSTIC PATH

Environment evidence:
NOT RUN

Changes authorized:
NONE

M3/M4:
NO CHANGE

---

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