ข้ามไปยังเนื้อหา

Engine Surface Maturity Audit

เนื้อหานี้ยังไม่ได้แปลเป็นภาษาไทย แสดงเป็นภาษาอังกฤษแทน

Surface maturity in this document reflects the repository state as of April 30, 2026.

Cephalon now ships a mix of:

  • taxonomy and descriptor surfaces
  • truthful runtime catalogs
  • managed execution or provisioning runtimes
  • adoption-ready tooling and operator experiences

That is healthy, but only if the repository says which kind of value each surface provides.

The current risk is not “metadata exists.” The risk is letting descriptor-first work read like execution ownership when the package does not yet own the runtime path.

This audit is the repo-owned answer for that distinction.

Every meaningful package or public/runtime surface should declare a current maturity target.

  • defines vocabulary, descriptors, or selection semantics
  • may shape scaffolding or planning language
  • does not claim runtime ownership by itself
  • publishes truthful descriptors, catalogs, runtime snapshots, or introspection
  • may validate configuration or authored intent
  • still does not claim managed execution or provisioning ownership
  • owns one real execution, orchestration, or provisioning path
  • publishes runtime state for that path
  • documents boundaries, failure modes, and ownership clearly
  • supports real operator workflows, reconciliation, or automation loops
  • exposes drill-down routes, lifecycle posture, and remediation-friendly runtime answers
  • proves recovery, drift, or live-state handling beyond a happy path
  • includes adoption-quality docs, samples/templates, and validation evidence
  • is ready to be described as a shipped baseline for downstream teams
  • keeps docs, runtime truth, tests, and packaging aligned

Maturity and ownership are related but different. Every surface should also describe who owns the real work:

  • taxonomy-only: vocabulary or modeling only
  • application-managed: consumer code or another runtime executes the work; Cephalon models or observes it
  • cephalon-managed: Cephalon owns the execution or provisioning path
  • provider-managed: a provider-specific Cephalon pack owns the execution or provisioning path

Intentional taxonomy-only and application-managed surfaces are valid. They just need to be labeled honestly.

SurfacePrimary roleOwnership modeCurrent maturityNext proof needed
Cephalon.Engine app model, manifest, runtime introspection, policy compositionCore runtime contract and compositioncephalon-managedM4Keep compatibility, docs, and generated surfaces aligned as new packs land
Cephalon.Cli, Cephalon.Scaffolding, Cephalon.TemplatePack, Cephalon.ReferenceDocsAdoption and packaging surfacecephalon-managedM4Maintain package/version/template/reference-doc alignment
Cephalon.Behaviors core runtime and durable executionBehavior execution substratecephalon-managedM4Continue adoption polish and guardrail coverage rather than adding parallel execution stories
Cephalon.Behaviors.Http module-owned behavior REST projectionREST profile metadata plus explicit module-owned public REST activation, Cephalon-managed materialization, governance, and runtime catalogsmixed: application-managed profile/publication activation plus cephalon-managed materialization/runtime catalog truthM2Keep profile metadata explicitly non-publishing and continue adoption/operator automation proof without inventing ambient REST publication
Cephalon.Data shared CDC runtime plus provider-native pumpsShared and provider-native data execution truthcephalon-managed plus provider-managedM3More package-level external adoption proof and operator docs per provider family
Cephalon.Edge.KubernetesGateway and Cephalon.Edge.TraefikProvider-specific control-plane automationprovider-managedM3More adoption-quality samples and package publishing guidance outside the repo
Cephalon.Eventing core packageChannel descriptors, staged publication, subscription runtime truth, public managed-execution binding catalog, abstraction-level subscription execution-readiness catalog, abstraction-level publication dispatcher, abstraction-level publication runtime-state catalog, abstraction-level dispatch-state/summary terminal-failure posture, /engine/event-subscription-readiness, POST /engine/event-publications, /engine/event-publications/runtime*, /engine/event-dispatches/terminal-failures, snapshot.EventSubscriptionExecutionReadiness, snapshot.EventPublicationStates, snapshot.EventDispatchStates, stable subscription runtime metadata vocabulary, opt-in direct in-process subscription execution, bounded process-local retry, and bounded process-local duplicate-completed execution suppressionmixed: application-managed descriptors/runtime reports plus cephalon-managed direct in-process execution, bounded process-local retry, bounded process-local idempotency, bounded publication action truth, publication runtime-state truth for direct execution or accepted outbox handoff, and typed dispatch terminal-failure operator truth over reported dispatch stateM3Keep the in-process lane, retry loop, idempotency guard, operator publication route, publication runtime-state catalog, and dispatch terminal-failure posture bounded to reported state; only claim generic broker/inbox/durable retry/downstream delivery ownership when a package truly owns those paths
Cephalon.Eventing.WolverineOptional Wolverine-managed staged dispatch, bounded managed-dispatch retry with terminal dispatch-store semantics, publish-exception terminal proof, first-class terminal dispatch operator posture through the shared eventing state/summary surfaces, subscription execution, bounded managed-subscription retry, and terminal exhausted-attempt failure baselineprovider-managedM3Broaden inbound-consumption, broker-specific dead-letter, and operator-automation proof only when the runtime truly owns those paths
Cephalon.AgenticsTool descriptors, managed tool dispatch, abstraction-level run-state catalog, bounded operator action route, bounded process-local executor retry posture, bounded process-local duplicate-completed suppression, approval-required and terminal-failure operator filters, /engine/agent-tool-runs, /engine/agent-tool-runs/retry-pending, /engine/agent-tool-runs/idempotency-duplicates, /engine/agent-tool-runs/approval-required, /engine/agent-tool-runs/terminal-failures, POST /engine/agent-tools/{toolId}/runs, snapshot.AgentToolRuns, and agent-workload runtime surfacemixed: application-managed descriptors plus cephalon-managed dispatcher/run-state/operator-action/bounded-process-local-retry/bounded-process-local-idempotency/read-filter baselineM3Broader agent operator workflows, durable approval workflows, durable retry queues, durable inboxes, memory persistence, dead-letter systems, cross-node exactly-once delivery, distributed scheduling, and provider-specific AI orchestration only after a package truly owns those paths
Cephalon.RetrievalKnowledge collection descriptors plus managed lexical indexing, query execution, freshness state, abstraction-level index-state catalog, abstraction-level bounded query command seam, manual reindex command seam, opt-in background reindex scheduler, /engine/knowledge-indexes, POST /engine/knowledge-indexes/{collectionId}/queries, POST /engine/knowledge-indexes/{collectionId}/reindex, and snapshot.KnowledgeIndexesmixed: application-managed source documents plus cephalon-managed index/query/operator-read/operator-query/manual-remediation/background-automation baselineM3Provider-specific vector/search engines, durable or distributed indexes, and distributed scheduler coordination only after a package truly owns those paths
Cephalon.MultiTenancy core packageNarrow tenant-resolution plus explicit governance-boundary runtime truthmixed: cephalon-managed tenant-resolution core plus boundary entries for companion-owned or planned workflowsM2Keep the base package focused on resolution while companion packages own concrete governance workflows
Cephalon.MultiTenancy.GovernanceTenant membership, invitation, delivery dispatch/retry/status reconciliation, delivery-status observation storage, tenant-administration, domain-ownership verification/proof collection/polling, governance action workflows, optional ASP.NET Core governance endpoints with bounded delivery-status observation reads, filtered rollup summaries, attention-category drill-downs, provider-message drill-downs, remediation-action filters, and remediation hints, optional HTTP/SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph senders, optional Microsoft Graph Azure Identity token provider, optional ASP.NET Core SendGrid callback translation plus signed-webhook verification, process-local replay protection, and observation-store-backed event-id idempotency, optional ASP.NET Core Mailgun callback translation plus HMAC signed-webhook verification, bounded process-local replay-token protection, and observation-store-backed event-id idempotency, and optional ASP.NET Core Amazon SES over SNS callback translation plus SNS signature verification, bounded process-local SNS replay protection, observation-store-backed SNS message-id idempotency, verified SNS subscription confirmation, and verified SNS unsubscribe-confirmation observationmixed: cephalon-managed governance core, ASP.NET Core adapter endpoints, filtered observation rollup summaries, attention-category drill-downs, provider-message drill-down filters, remediation-action filters, remediation hints over matched normalized observations, provider-neutral callback signatures, bounded process-local replay protection, local durable stores, HTTP/SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph sender companions, Microsoft Graph Azure Identity token-provider companion, SendGrid callback translation/signature verification/process-local replay/event-id-idempotency protection, Mailgun callback translation/signature verification/process-local replay-token/event-id-idempotency protection, and Amazon SES over SNS callback translation, opt-in SNS signature verification, bounded process-local SNS replay protection, observation-store-backed SNS message-id idempotency, opt-in verified SNS subscription confirmation, and opt-in verified SNS unsubscribe-confirmation observation; external provider delivery/status, distributed remediation execution, Microsoft Entra tenant governance, AWS account/identity governance, SNS topic/subscription creation, automatic resubscribe/restore, and subscription lifecycle governance remain provider-managedM2Actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond state transitions, distributed or provider-backed membership/invitation/domain/action-store backends, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, distributed retry queues, cross-node retry leases, provider-specific or distributed callback inboxes, cross-node callback replay protection, distributed event-id ledgers, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, identity-provider synchronization, public onboarding, and tenant-admin UI/backoffice flows only when the package truly owns those paths
Cephalon.AuditAudit-recording host-agnostic baseline: IAuditRecorder service, IAuditActorAccessor ambient actor contract, default in-memory IAuditWriter baseline (configurable through Engine:Audit:EnableInMemoryWriter), IAuditStoreCatalog projection through /engine/audit-stores and snapshot.AuditStores, additive IAuditHistoryReader and IAuditHistoryExporter contracts, stable diagnostics conventions for audit-entry write success/failuremixed: cephalon-managed in-memory writer baseline plus catalog projection plus ambient actor resolution; application-managed consumer-supplied actor accessors and durable storage opinionM1Durable provider-pack proof beyond Cephalon.Audit.EntityFramework, distributed audit ledgers, query-server adapters, and any cross-host actor governance only after a package owns those paths
Cephalon.Audit.EntityFrameworkDurable Entity Framework audit history: Engine:Audit:History configuration plus Engine:Databases role contract, queryable IAuditHistoryReader implementation, bounded IAuditHistoryExporter NDJSON path, retention guidance through Engine:Audit:History:Retentionprovider-managedM1Distributed audit-history backends, replication-aware reader/exporter coordination, and cross-host retention enforcement only after the runtime owns those paths
Cephalon.IdentityHost-agnostic identity and authorization baseline: metadata-driven IAuthorizationEvaluator default (configurable through Engine:Identity:EnableDefaultEvaluator), IAuthorizationPolicyCatalog projection through /engine/authorization-policies and snapshot.AuthorizationPolicies, identity-authorization technology runtime surface (configurable through Engine:Identity:EnableRuntimeSurface), dedicated diagnostics conventionmixed: cephalon-managed default metadata-driven evaluator, runtime surface, catalog projection, and diagnostics conventions; application-managed identity scheme, principal flow, and any product-specific policy engineM1Broader runtime authorization-decision proof, durable policy stores, distributed evaluation caches, and provider-specific identity-provider sync only after a package owns those paths
Cephalon.Identity.AspNetCoreASP.NET Core integration baseline: minimal-API and controller-action policy mapping over the host-agnostic evaluator, optional projection of authenticated ClaimsPrincipal into the ambient IAuditActorAccessor contract when Cephalon.Audit is activeapplication-managedM1Deeper host/runtime truth such as endpoint-policy catalogs, scheme-aware diagnostics, and per-request decision projection only after the adapter package owns those paths; do not push ASP.NET Core concerns back into Cephalon.Abstractions
Cephalon.Ids.SfidSnowflake-style identifier generator: Cephalon.Abstractions.Ids.IIdGenerator over the official Sfid.Net generator, SfidNet.Abstractions.ISfidGenerator projection for companion packs, AppProfile.Data.IdGenerator = sfid runtime selection, optional generator topology through Engine:Data:Ids:Sfidcephalon-managedM2Additional generator topologies (cluster-aware sequencing, time-shard rotation) and managed-clock observability only when the runtime owns those paths
Cephalon.EventSourcing and provider packs (Cephalon.EventSourcing.EntityFramework, Cephalon.EventSourcing.MongoDB, Cephalon.EventSourcing.Redis, Cephalon.EventSourcing.Neo4j, Cephalon.EventSourcing.Cassandra, Cephalon.EventSourcing.ClickHouse, Cephalon.EventSourcing.Elasticsearch, Cephalon.EventSourcing.OpenSearch, Cephalon.EventSourcing.Qdrant, Cephalon.EventSourcing.Nats)Event-sourced aggregate contracts, descriptors, and provider-specific store catalogs without managed-execution proof in the engineapplication-managed aggregate logic plus provider-managed per-pack store contractsM1 (family-level)Managed event-store execution proof (append/read/projection lifecycle) per provider pack before promoting any individual pack from M1 catalog-only to M2 managed-execution; the catalog-only stance is intentional until those proofs ship
Cephalon.Observability core plus exporter and dependency-health companion familyShared observability options, startup summary projection, telemetry-export configuration intent, optional OpenTelemetry/Serilog/Kubernetes/AWS/GCP/Azure Monitor/Alibaba Cloud/Huawei Cloud/Oracle Cloud/DigitalOcean/OpenShift/Tanzu/Grafana Cloud/New Relic configuration packs, optional dependency-health probe core plus per-provider probe packs (Cassandra, ClickHouse, Consul, Elasticsearch, Http, Kafka, Memcached, MongoDB, MQTT, MySQL, NATS, Neo4j, OpenSearch, Oracle, PostgreSQL, RabbitMQ, Redis, SqlServer)cephalon-managed for the observability core, configuration packs, and dependency-health probe baselines; taxonomy-only for per-provider dependency-health probe packs that ship descriptors without a probe runtime of their ownCephalon.Observability core at M2; cloud configuration packs and Cephalon.Observability.DependencyHealth.Core at M1; per-provider dependency-health probe packs at M0Genuine telemetry collection happens in the host runtime’s OpenTelemetry stack; only promote a configuration pack above M1 when it owns runtime collection or a managed exporter loop, and only promote a dependency-health probe pack above M0 when it owns a probe runtime, not just a descriptor
Multi-tenancy invitation delivery sender family (Cephalon.MultiTenancy.Governance.HttpDelivery, .SmtpDelivery, .SendGridDelivery, .MailgunDelivery, .AmazonSesDelivery, .MicrosoftGraphDelivery plus .SendGridDelivery.AspNetCore, .MailgunDelivery.AspNetCore, .AmazonSesDelivery.AspNetCore, .MicrosoftGraphDelivery.AzureIdentity)Provider-neutral host-agnostic invitation-sender contract plus shipped HTTP webhook / SMTP relay / SaaS API / Microsoft Graph senders, optional ASP.NET Core callback translation, signed-webhook verification, bounded process-local replay protection, observation-store-backed event-id idempotency, and the Azure Identity token-provider companion that serves the Microsoft Graph sendercephalon-managed shared dispatch contract, callback translation, signed-webhook verification, replay protection, idempotency stores; the senders’ upstream provider services remain provider-managed outside the engineM2 family-wide; promote a single sender above the family floor only when that sender owns adoption-quality proof beyond the shared dispatch + callback contract that justifies independent maturity languageAll six senders share the M2 label by design: each owns the same managed dispatch, the same callback handling shape (where applicable), and the same replay/idempotency hygiene over a different upstream API. Per-sender promotion requires (a) provider-specific adoption proof unique to one sender (deeper reconciler, distributed retry queue, identity-provider sync, etc.), and (b) matching matrix row + component doc + planning record updates in one slice. Until then, treat the family floor as M2 and the per-sender component docs as the per-sender adoption truth
  • stop expanding descriptor-first surfaces inside mixed-maturity families unless the work is explicitly labeled M0 or M1
  • do not describe M0 or M1 packages as if they already own execution, orchestration, or provisioning
  • treat the Cephalon.Eventing in-process direct subscription lane plus bounded process-local retry, bounded process-local idempotency, POST /engine/event-publications, /engine/event-publications/runtime*, and first-class terminal dispatch-state operator posture, the optional Cephalon.Eventing.Wolverine provider-managed dispatch/subscription lane plus bounded terminal dispatch and subscription retry proof, the Cephalon.Agentics dispatcher/run-state lane plus direct operator read/action seams, bounded process-local executor retry posture, bounded process-local duplicate-completed suppression, approval-required filter, and terminal-failure filter, and the Cephalon.Retrieval lexical index/query/freshness lane plus direct operator read, bounded query action, manual reindex, and opt-in background reindex seams as current managed vertical proofs instead of widening descriptor breadth before ownership is real
  • keep Cephalon.MultiTenancy intentionally thin in the base package; the governance family now owns the concrete governance workflows plus optional ASP.NET Core routes, HTTP/SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph sender companions, Microsoft Graph Azure Identity token-provider companion, provider-neutral callback signatures/replay protection, filtered observation rollup summaries, attention-category drill-downs, provider-message drill-down filters, remediation-action filters, remediation hints over matched normalized observations, optional SendGrid callback translation plus signed-webhook verification, bounded process-local signed-callback replay protection, observation-store-backed SendGrid event-id idempotency, optional Mailgun callback translation plus HMAC signed-webhook verification, bounded process-local replay-token protection, observation-store-backed Mailgun event-id idempotency, optional Amazon SES over SNS callback translation, opt-in SNS signature verification, bounded process-local SNS replay protection, observation-store-backed Amazon SNS message-id idempotency, opt-in verified SNS subscription confirmation, and opt-in verified SNS unsubscribe-confirmation observation. Actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond state transitions, distributed or provider-backed membership/invitation/domain/action stores, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider senders, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, distributed retry queues, cross-node retry leases, provider-specific or distributed callback inboxes, cross-node callback replay protection, distributed event-id ledgers, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, identity-provider synchronization, public onboarding, and tenant-admin UI/backoffice flows remain explicitly outside the current claim
  • treat the ASP.NET Core invitation delivery dispatch endpoint as a bounded M2 action seam over the host-agnostic dispatcher, and treat the delivery-status observation read endpoint plus filtered rollup summaries, attention-category drill-downs, provider-message drill-down filters, remediation-action filters, and remediation hints as a bounded M2 operator/audit projection over normalized store records; do not promote either endpoint into provider-specific sender ownership, distributed retry queues, callback-inbox, provider-polling, distributed remediation execution, distributed-replay, or exactly-once language until a package owns those paths
  • use Cephalon.Behaviors, Cephalon.Behaviors.Http, Cephalon.Data, and the shipped edge provider packs as the current examples of truthful runtime ownership
  • ENG-230 Engine surface maturity model and audit baseline (shipped)
  • ENG-231 Truthful managed event-subscription execution baseline (shipped)
  • ENG-232 Agentics tool execution and run-state baseline (shipped)
  • ENG-233 Retrieval indexing, query execution, and freshness baseline (shipped)
  • ENG-234 Multi-tenancy governance, membership, and domain workflow companion split (shipped)
  • ENG-235 Multi-tenancy governance membership evaluation baseline (shipped)
  • ENG-236 Multi-tenancy governance invitation validation baseline (shipped)
  • ENG-237 Multi-tenancy governance domain ownership validation baseline (shipped)
  • ENG-238 Multi-tenancy governance action decision baseline (shipped)
  • ENG-239 Multi-tenancy governance action workflow execution baseline (shipped)
  • ENG-240 Multi-tenancy governance durable action store baseline (shipped)
  • ENG-241 Multi-tenancy governance durable membership store baseline (shipped)
  • ENG-242 Multi-tenancy governance durable invitation store baseline (shipped)
  • ENG-243 Multi-tenancy governance durable domain ownership store baseline (shipped)
  • ENG-244 Multi-tenancy governance domain ownership verification workflow baseline (shipped)
  • ENG-245 Multi-tenancy governance domain ownership proof evaluation baseline (shipped)
  • ENG-246 Multi-tenancy governance domain ownership proof challenge issuance baseline (shipped)
  • ENG-247 Multi-tenancy governance domain ownership proof publication planning baseline (shipped)
  • ENG-248 Multi-tenancy governance domain ownership HTTP proof collection baseline (shipped)
  • ENG-249 Multi-tenancy governance domain ownership proof verification runner baseline (shipped)
  • ENG-250 Multi-tenancy governance domain ownership DNS TXT proof collection baseline (shipped)
  • ENG-251 Multi-tenancy governance domain ownership proof polling runner baseline (shipped)
  • ENG-252 Multi-tenancy governance automatic background proof polling baseline (shipped)
  • ENG-253 Multi-tenancy governance HTTP proof publication baseline (shipped)
  • ENG-254 Multi-tenancy governance tenant administration workflow baseline (shipped)
  • ENG-255 Multi-tenancy governance ASP.NET Core tenant administration endpoint baseline (shipped)
  • ENG-256 Multi-tenancy governance invitation delivery dispatch baseline (shipped)
  • ENG-257 Multi-tenancy governance HTTP invitation delivery sender baseline (shipped)
  • ENG-258 Multi-tenancy governance HTTP invitation delivery webhook signing baseline (shipped)
  • ENG-259 Multi-tenancy governance HTTP invitation delivery retry baseline (shipped)
  • ENG-260 Multi-tenancy governance HTTP invitation delivery idempotency baseline (shipped)
  • ENG-261 Multi-tenancy governance invitation delivery status reconciliation baseline (shipped)
  • ENG-262 Behavior REST profile runtime ownership metadata baseline (shipped)
  • ENG-263 Eventing subscription execution binding catalog baseline (shipped)
  • ENG-264 Eventing subscription execution readiness catalog baseline (shipped)
  • ENG-265 Eventing subscription readiness operator-surface baseline (shipped, issue #774)
  • ENG-266 Agentics tool-run operator-surface baseline (shipped, issue #775)
  • ENG-267 Retrieval knowledge-index operator-surface baseline (shipped, issue #776)
  • ENG-268 Retrieval reindex operator-action baseline (shipped, issue #777)
  • ENG-269 Agentics tool execution operator-action baseline (shipped, issue #778)
  • ENG-270 Retrieval background reindex scheduler baseline (shipped, issue #779)
  • ENG-271 Eventing in-process subscription execution baseline (shipped, issue #780)
  • ENG-272 Eventing publication operator action baseline (shipped, issue #781)
  • ENG-273 Eventing in-process subscription retry baseline (shipped, issue #782)
  • ENG-274 Eventing in-process subscription idempotency baseline (shipped, issue #783)
  • ENG-275 Eventing publication runtime operator-state baseline (shipped, issue #784)
  • ENG-276 Wolverine bounded subscription retry terminal failure (shipped, issue #785)
  • ENG-277 Wolverine dispatch terminal retry failure (shipped, issue #786)
  • ENG-278 Wolverine dispatch publish-exception terminal proof (shipped, issue #787)
  • ENG-279 first-class event-dispatch terminal-failure runtime posture (shipped, issue #788)
  • ENG-280 Agentics bounded in-process retry posture (shipped, issue #789)
  • ENG-281 Agentics process-local duplicate-run idempotency posture (shipped, issue #790)
  • ENG-282 Agentics approval-required and terminal-failure operator posture (shipped, issue #791)
  • ENG-283 Retrieval query operator action seam (shipped, issue #792)
  • ENG-284 Multi-tenancy invitation delivery status callback endpoint baseline (shipped, issue #793)
  • ENG-285 Multi-tenancy invitation delivery status callback signature verification baseline (shipped, issue #800)
  • ENG-286 Multi-tenancy invitation delivery status callback replay protection baseline (shipped, issue #801)
  • ENG-287 Multi-tenancy invitation delivery status observation store baseline (shipped, issue #802)
  • ENG-288 Multi-tenancy invitation delivery status observation endpoint baseline (shipped, issue #803)
  • ENG-289 Multi-tenancy invitation delivery dispatch endpoint baseline (shipped, issue #804)
  • ENG-290 Multi-tenancy invitation delivery durable retry queue baseline (shipped, issue #805)
  • ENG-291 Multi-tenancy invitation delivery background retry scheduling baseline (shipped, issue #806)
  • ENG-292 Multi-tenancy invitation delivery retry execution coordination baseline (shipped, issue #807)
  • ENG-293 Multi-tenancy invitation delivery SMTP sender baseline (shipped, issue #808)
  • ENG-294 Multi-tenancy invitation delivery SendGrid sender baseline (shipped, issue #809)
  • ENG-295 Multi-tenancy invitation delivery SendGrid Event Webhook callback translation baseline (shipped, issue #810)
  • ENG-296 Multi-tenancy invitation delivery SendGrid signed Event Webhook verification (shipped, issue #811)
  • ENG-297 Multi-tenancy invitation delivery SendGrid signed Event Webhook replay protection baseline (shipped, issue #812)
  • ENG-298 Multi-tenancy invitation delivery SendGrid event-id idempotency baseline (shipped, issue #813)
  • ENG-299 Multi-tenancy invitation delivery Mailgun sender baseline (shipped, issue #814)
  • ENG-300 Multi-tenancy invitation delivery Mailgun webhook callback translation baseline (shipped, issue #815)
  • ENG-301 Multi-tenancy invitation delivery Mailgun signed webhook verification baseline (shipped, issue #816)
  • ENG-302 Multi-tenancy invitation delivery Mailgun signed webhook replay protection baseline (shipped, issue #817)
  • ENG-303 Multi-tenancy invitation delivery Mailgun event-id idempotency baseline (shipped, issue #818)
  • ENG-304 Multi-tenancy invitation delivery Microsoft Graph sender baseline (shipped, issue #819)
  • ENG-305 Multi-tenancy invitation delivery Microsoft Graph Azure Identity token provider baseline (shipped, issue #820)
  • ENG-306 Multi-tenancy invitation delivery Amazon SES sender baseline (shipped, issue #821)
  • ENG-307 Multi-tenancy invitation delivery Amazon SES SNS callback translation baseline (shipped, issue #822)
  • ENG-308 Multi-tenancy invitation delivery Amazon SES SNS signature verification baseline (shipped, issue #823)
  • ENG-309 Multi-tenancy invitation delivery Amazon SES SNS replay protection baseline (shipped, issue #824)
  • ENG-310 Multi-tenancy invitation delivery Amazon SES SNS message-id idempotency baseline (shipped, issue #825)
  • ENG-311 Multi-tenancy invitation delivery Amazon SES SNS subscription confirmation baseline (shipped, issue #826)
  • ENG-312 Multi-tenancy invitation delivery Amazon SES SNS unsubscribe confirmation observation baseline (shipped, issue #827)
  • ENG-313 Multi-tenancy delivery status observation rollup operator summary (shipped, issue #828)
  • ENG-314 Multi-tenancy delivery status observation attention drill-down baseline (shipped, issue #829)
  • ENG-315 Multi-tenancy delivery status observation remediation hints baseline (shipped, issue #830)
  • ENG-316 Multi-tenancy delivery status observation remediation action filter baseline (shipped, issue #831)
  • ENG-317 Multi-tenancy delivery status observation provider-message drill-down baseline (shipped, issue #832)
  • actual DNS proof publication, provider-backed proof publication or mutation, remediation execution beyond state transitions, distributed or provider-backed membership/invitation/domain/action-store backends, additional provider-specific email API senders beyond the shipped SMTP/SendGrid/Mailgun/Amazon SES/Microsoft Graph set, SMS/chat/CRM/identity-provider invitation senders, Microsoft Entra app registration/permission consent/mailbox access policy, AWS account/IAM/identity verification, DKIM/SPF/DMARC, SES sandbox/configuration-set event destination setup, SNS topic/subscription creation, automatic resubscribe/restore, subscription lifecycle governance, distributed retry queues, cross-node retry leases, provider-specific or distributed callback inboxes, cross-node callback replay protection, provider-specific callback payload translation beyond shipped SendGrid/Mailgun/Amazon SES translators, provider-specific callback signature verification beyond shipped SendGrid/Mailgun/Amazon SNS hardening, provider polling, identity-provider synchronization, public onboarding, and tenant-admin UI/backoffice flows when Cephalon.MultiTenancy.Governance or provider packs truly own those paths

Before a surface claims the next maturity level, confirm the proof is real:

  1. M0 -> M1: truthful runtime or catalog answer exists and docs say what is not owned yet.
  2. M1 -> M2: one managed path exists end to end, including runtime state, failure posture, and ownership language.
  3. M2 -> M3: operators can observe, reconcile, or remediate the path without relying on hidden knowledge.
  4. M3 -> M4: samples, package docs, validation, compatibility/readiness guidance, and planning truth all match the shipped behavior.

When a new runtime or package surface lands, the same slice should update:

  • source
  • component docs
  • this audit when maturity or ownership changes
  • roadmap and backlog entries
  • compatibility or readiness docs if the public/package contract changes
  • samples, tests, and benchmarks when the claimed maturity requires them

The goal is not to force every surface to become M4.

The goal is to make each surface honest, intentional, and easy to adopt.