TenantAtlas/specs/043-cross-tenant-compare-and-promotion/spec.md
ahmido dedca3c612 spec: add inventory specs 039-044 (#42)
What’s included
	•	specs/039-inventory-program/ — program/epic overview (vision + phased plan)
	•	specs/041-inventory-ui/ — UI skeleton (Inventory list, Coverage, Sync Runs)
	•	specs/042-inventory-dependencies-graph/ — dependency graph skeleton (assignments/filters/scope tags → later)
	•	specs/043-cross-tenant-compare-and-promotion/ — compare/promotion skeleton (read-only first; writes gated later)
	•	specs/044-drift-mvp/ — drift detection skeleton (read-only by default)

Why

We need a clear, spec-first structure for:
	•	separating Inventory (“last observed”) from Snapshots/Backups (immutable)
	•	scaling to MSP / multi-tenant workflows (portfolio, compare, monitoring)
	•	making future modules (security suite, drift, promotion) consistent with the Constitution (fail-safe, auditability, contract-driven Graph)

Scope / Non-goals (this PR)
	•	No implementation tasks executed
	•	No DB migrations, services, jobs, or UI changes
	•	No changes to Graph contracts or supported policy types

Review focus
	•	Naming/numbering and folder structure (spec.md, plan.md, tasks.md for each spec)
	•	Scope boundaries and non-goals across 041–044
	•	Alignment with Constitution principles (tenant isolation, read-only default for analysis, explicit gating for high-risk writes)

Follow-up (next PRs)
	•	Spec 040: Inventory Core (data model + selection hash + missing semantics + NFRs + tests)
	•	Implementation PRs will be split per spec (040 → 041 → 042/043/044)

⸻

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #42
2026-01-07 14:01:07 +00:00

2.0 KiB

Feature Specification: Cross-tenant Compare and Promotion

Feature Branch: feat/043-cross-tenant-compare-and-promotion
Created: 2026-01-07
Status: Draft

Purpose

Enable safe cross-tenant comparison of inventory and, optionally, controlled promotion workflows.

Comparison is read-only by default. Any write/promotion behavior must be explicitly gated, audited, and separately authorized.

User Scenarios & Testing

Scenario 1: Compare two tenants (read-only)

  • Given the operator has access to Tenant A and Tenant B
  • When they select two tenants and a set of policy types
  • Then they can see differences in presence and key metadata

Scenario 2: Compare with a stable reference

  • Given a reference selection scope
  • When the operator runs comparison
  • Then results are stable and reproducible for that scope

Scenario 3: Promotion is explicitly gated (optional)

  • Given promotion is enabled by policy
  • When the operator initiates promotion
  • Then the system requires explicit confirmation and records an audit event

Functional Requirements

  • FR1: Support selecting two tenants within authorized scope.
  • FR2: Provide read-only diff views based on inventory metadata and stable identifiers.
  • FR3: Provide exportable comparison results.
  • FR4: If promotion is included:
    • require explicit enablement
    • require explicit confirmation per operation
    • record audit logs
    • support dry-run/preview

Non-Functional Requirements

  • NFR1: Enforce tenant isolation and least privilege across tenant selection and data access.
  • NFR2: Comparison must not expose secrets or unsafe payload fields.

Success Criteria

  • SC1: Operators can identify which tenant differs for a given policy type in under 2 minutes.
  • SC2: Read-only comparisons are reproducible when run again with the same scope.

Out of Scope

  • Bulk remediation without preview/confirmation.
  • Program: specs/039-inventory-program/spec.md
  • Core: specs/040-inventory-core/spec.md
  • Drift: specs/044-drift-mvp/spec.md