Skip to main content

Operationalization RFC

Implementation planning package

This page packages the operationalization work in RFC form so the team can discuss the problem, proposed direction, dependencies, risks, and decisions in one place.

RFC scope

  • identity and access model
  • org-aware entitlements
  • Kanopy internal runtime
  • observability and analytics baseline

Problem​

Builder Insights is evolving from a useful product workflow into an internal platform. The app can demonstrate value, but identity, org-aware access, internal hosting, and telemetry are not yet fully operationalized. Without those layers, internal trust, scale, and supportability remain fragile.

Proposal​

Identity

Adopt MongoDB Okta SSO as the workforce identity path and map trusted claims into product roles through an entitlement layer.

Org truth

Use an approved internal org source to determine Builder Relations membership and any reporting-line-aware visibility rules.

Runtime

Move the admin control plane and internal service layer toward Kanopy as the internal hosting model.

Visibility

Implement a minimum baseline of logs, metrics, audit events, and usage analytics before broader internal rollout.

Non-goals​

  • redesigning the product role model from scratch
  • defining every future dashboard in final detail immediately
  • solving all mobile distribution questions in the same phase as web/control-plane hosting

Dependencies​

DependencyWhy it matters
Okta and identity guidanceneeded to define the workforce sign-in path and trusted claims
Builder Relations org sourceneeded to make entitlements and reporting scopes defensible
Kanopy platform guidanceneeded to define internal runtime assumptions and deployment expectations
Telemetry stack approvalneeded to turn observability from aspiration into implementation

Risks​

Risk

Primary implementation risks

  • identity and access remain ambiguous and block production-ready rollout
  • org-aware access is approximated instead of sourced from a trusted internal system
  • Kanopy migration is attempted before auth and ingress assumptions are stable
  • telemetry remains too weak to support confident internal operation

Open questions​

  • which Okta integration pattern is preferred for this class of internal app?
  • which system is authoritative for Builder Relations membership and hierarchy?
  • which workloads move into Kanopy first?
  • which telemetry stack and dashboard ownership model are approved internally?

Decisions needed​

DecisionNeeded from
Okta SSO path and claims modelIdentity and Security
Builder Relations org sourceBuilder Relations Ops and Org Systems
First Kanopy runtime boundaryPlatform Engineering and Application Engineering
Telemetry and dashboard ownership modelPlatform Engineering, Product, and Application Engineering

Shared status vocabulary​

Use the same planning statuses across the operationalization docs:

  • In discovery
  • Drafted
  • Needs decision
  • Needs validation
  • Blocked

These statuses should mean the same thing in the dashboard, decision register, and workstream pages.

Success criteria​

Access is defensible

The team can explain who signs in, how roles are assigned, and how privileged access is reviewed.

Runtime is supportable

The internal-facing runtime has a clear hosting model, environment strategy, and rollback posture.

Platform is measurable

Reliability, usage, and sensitive actions are visible through telemetry and dashboards.

Readiness is reviewable

Broader internal rollout uses an explicit readiness gate rather than intuition alone.