---
name: L7 Cross-Platform Glue - {{instance_name}}
description: L7 cross-platform glue artifact for {{instance_name}}. Captures every concern that crosses L5 instances. Six concerns are surveyed by Q8 - shared memory, shared identity, handoff protocol, consent flow, alerting fabric, monitoring base. L7 is the most-skipped layer; explicit population defeats the omission.
type: layer-artifact
layer: L7
populated_from: Q8 (cross-platform glue), Q7 (instances participating in each concern)
---

# L7 Cross-Platform Glue - {{instance_name}}

- **Last reviewed:** {{capture_date}}
- **Review cadence:** quarterly + on every new L5 instance addition
- **Status:** active

> *Build-flavored examples in this template (feature-flag service, JWT, queue envelopes, etc.). Operator / decider / creator deployments populate the same six concerns with translated content (per ADR-0006). The six concerns themselves are universal.*

## Maturity self-assessment

L7 has six standard concerns; report each separately. None of these may report as `unknown` per Q8's hard rule.

| Concern | State | Owner | Last verified live |
|---------|-------|-------|--------------------|
| Shared memory | exists-mature / exists-partial / declared-not-built / none-applicable | {{owner}} | {{date}} or never |
| Shared identity | ... | ... | ... |
| Handoff protocol | ... | ... | ... |
| Consent flow | ... | ... | ... |
| Alerting fabric | ... | ... | ... |
| Monitoring base | ... | ... | ... |

Concerns marked `none-applicable` must include a one-sentence justification in the section below. Concerns marked `declared-not-built` must include a closes-by date or `unscheduled - flagged in BACKLOG`.

## Why L7 is reported with this much rigor

L7 is the most-commonly missed layer. Junior actors stop at L5 and treat anything cross-cutting as L4 (the kit). They are different. L4 is what each instance pulls *from*. L7 is what crosses *between* instances. A consent flow every instance must call is L7. A prompt template every instance forks is L4.

Reporting L7 with named concerns and explicit live-vs-declared classification defeats the omission failure mode by structure rather than by discipline.

---

## Concern 1: Shared memory

- **State:** {{state_token}}
- **What it means here:** {{shared_memory_definition_for_this_function}}
- **Implementation:** {{implementation_path_or_external_system}}
- **Schema (if exists):** {{schema_summary}}
- **Participants (which L5 instances):** {{instance_list}}
- **Owner:** {{owner}}
- **Last verified live:** {{date_or_never}}

Example shape: "Shared memory means: cross-instance facts about a single MQL ({{score}}, {{enrichment}}, {{routing_history}}) that any of the L5 platforms may read or update. Implementation: `{{warehouse_table}}` with a single source-of-truth schema; participants read via the kit's data-access library. Schema: see `cross-platform/shared-memory-schema.md`. Participants: `mql-router`, `mql-enrichment-service`, `sdr-handoff-helper`. Owner: {{owner_team}}. Last verified live: 2026-04-22 - confirmed via end-to-end trace through three platforms."

If `none-applicable`, this section reads: "N/A. {{justification}}."

## Concern 2: Shared identity

- **State:** {{state_token}}
- **What it means here:** {{shared_identity_definition}}
- **Implementation:** {{idp_or_token_format}}
- **Trust boundary:** {{boundary}}
- **Participants:** {{instance_list}}
- **Owner:** {{owner}}
- **Last verified live:** {{date_or_never}}

Example: "Shared identity means: a single tenant identity propagates through every L5 instance call chain so each instance can authorize against the same tenant scope. Implementation: tenant-scoped JWT issued by {{idp_name}}; all instances validate against {{jwks_endpoint}}. Trust boundary: tenant-id in claim is authoritative; mismatched claims hard-reject. Participants: every L5 instance. Owner: {{platform_team}}. Last verified live: 2026-04-26 - audit trace confirmed claim propagation."

## Concern 3: Handoff protocol

- **State:** {{state_token}}
- **What it means here:** {{handoff_definition}}
- **Implementation:** {{handoff_implementation}}
- **Schema (handoff envelope):** {{envelope_schema}}
- **Participants:** {{instance_list}}
- **Owner:** {{owner}}
- **Last verified live:** {{date_or_never}}

Example: "Handoff protocol means: when one platform completes its part of the workflow, the next platform receives a structured envelope with state, history, and confidence. Implementation: `cross-platform/handoff-envelope.json` schema; transport via {{queue_or_sync_call}}. Participants: all routing-stage platforms. Owner: {{owner_team}}. Last verified live: 2026-04-25."

## Concern 4: Consent flow

- **State:** {{state_token}}
- **What it means here:** {{consent_definition}}
- **Implementation:** {{consent_storage_and_check}}
- **Compliance regime alignment:** {{regimes_consent_satisfies}}
- **Participants:** {{instance_list}}
- **Owner:** {{owner}}
- **Last verified live:** {{date_or_never}}

Example: "Consent flow means: every L5 instance that touches PII checks the consent record before processing and respects revocation in real time. Implementation: `consent-service` API; cached with 5-minute TTL; revocation triggers cache invalidation across pods. Compliance: GDPR Art. 7 + 17. Participants: every L5 that touches PII. Owner: {{compliance_engineering}}. Last verified live: 2026-04-20 - revocation test confirmed propagation within 3 minutes."

If function does not touch user data, this section reads: "N/A. {{instance_name}} processes only {{non_user_data}}; no consent surface required."

## Concern 5: Alerting fabric

- **State:** {{state_token}}
- **What it means here:** {{alerting_definition}}
- **Implementation:** {{alert_routing_and_destination}}
- **Severity tiers:** {{severity_tiers}}
- **Participants:** {{instance_list}}
- **Owner:** {{owner}}
- **Last verified live:** {{date_or_never}}

Example: "Alerting fabric means: a unified alert routing path so any L5 instance can emit a tiered alert that reaches the right responder. Implementation: alerts emit to {{alerting_destination}}; routing rules in `cross-platform/alert-routing.yaml`. Tiers: P0 (customer-impacting), P1 (degradation), P2 (drift). Participants: every L5 instance + the L4 telemetry pipeline. Owner: {{ops_team}}. Last verified live: 2026-04-27 - synthetic P1 firing reached oncall in 2 min 14 sec."

## Concern 6: Monitoring base

- **State:** {{state_token}}
- **What it means here:** {{monitoring_definition}}
- **Implementation:** {{dashboards_and_metrics}}
- **Dashboard URL or path:** {{dashboard_link}}
- **Participants:** {{instance_list}}
- **Owner:** {{owner}}
- **Last verified live:** {{date_or_never}}

Example: "Monitoring base means: a shared dashboard suite covering health, cost, quality, and drift across every L5 instance. Implementation: {{observability_platform}} board {{board_id}}, fed from L4 telemetry plumbing. Participants: every L5 instance. Owner: {{ops_team}}. Last verified live: dashboard refreshed within last 24 hours; oncall checks at start of each shift."

## Cross-instance dependencies

A directed graph of which L5 instances participate in which L7 concerns. Helpful for impact-scoping before any cross-cutting change.

```
mql-enrichment-service ──participates──▶ shared-memory, shared-identity, alerting, monitoring
                                                   ▲             ▲           ▲          ▲
mql-router  ────────────participates────────────────┘             │           │          │
                                                                  │           │          │
sdr-handoff-helper ──participates──▶ handoff-protocol, shared-identity, monitoring
                                                   ...
```

## Inheritance and dependencies

This L7 inherits from: organization-level identity / consent / alerting / monitoring conventions if any. Name them or mark `none-existed-before-this-deployment`.

This L7 is consumed by: every L5 instance dossier (each declares its participation in each concern).

## Cross-references inside this instance

- `policies/philosophy.md` (L2) - the red lines that consent and PII rules implement
- `policies/framework-contract.md` (L3) - the telemetry and auth fields that feed monitoring and identity
- `kit/telemetry/` (L4) - feeds the monitoring base
- `platforms/{{platform_name}}/` (L5) - each dossier names its L7 participation
- `inbox/` - inbound entries from cross-pod ops if alerting fires
- `decisions/` - ADRs that touch any cross-cutting concern live here
