Capability status language
Proven
Demonstrated end to end with current operational evidence.
Operational
Implemented and used with documented controls and constraints.
Governed
Implemented behind approval, policy, or environment-specific enablement.
Portable pattern
Architecture is reusable, but a new external tenant or environment still requires its own proof.
Verified capability matrix
| Domain | Current capability | Status | Proof and boundary |
|---|---|---|---|
| SCIM users | Discovery, create, read, replace, patch, active-state disable, filters, paging, structured errors, and replay-safe behavior. | Proven | Standard SCIM transactions backed by FreeIPA-aware mapping and correlated evidence. |
| Password convergence | Password values delivered in an authorized SCIM transaction can be accepted in memory, policy-checked, pushed into FreeIPA, and proven through a downstream Linux login. | Proven | Plaintext is never persisted, echoed, or logged; gates control eligible flows and evidence records only the transaction outcome. |
| SAML SSO | Okta authentication, MFA handoff, ACS validation, role mapping, session establishment, logout, readiness, and diagnostics. | Proven | Human login remains distinct from machine provisioning. |
| OIDC | RP and broker control-plane integration, discovery and JWKS readiness, authorization-code security controls, role mapping, session evidence, protocol parity, and governed enablement. | Operational | Runs in parallel with SAML; deployment policy decides which path is enabled for a given environment. |
| FreeIPA control | Users, groups, HBAC, host groups, identity probes, bounded agent operations, directory health, and Linux enforcement evidence. | Proven | FreeIPA remains the Linux authorization and Kerberos/POSIX authority. |
| Foreman and Puppet | Host and interface inventory, MAC enrichment, Puppet facts, host-group context, fleet readiness, and controlled import with dry-run and backups. | Operational | Enrichment augments workstation truth without silently overwriting reviewed inventory. |
| Classroom operations | Room and seat views, multi-signal health, per-seat WoL, reboot and power-off paths, reason capture, status probes, and policy gates. | Proven | Power paths are scoped per workstation and separated by relay/SSH authority. |
| Remote console | Inventory-driven Guacamole SSH and VNC session planning, tokenized launch URLs, dedicated jump relays, VNC vortex activation, and audit trails. | Operational | Launchability depends on the workstation and jump-vantage path; secrets are outside the repository. |
| Topology | Living estate graph for application, identity, directory, Foreman, storage, relays, rooms, workstations, protocols, health, and evidence links. | Proven | Configured, inferred, cached, and live states are labeled rather than blended. |
| Living ERD | Database schema inventory and relationship visualization tied to the running platform model. | Operational | Operators can inspect schema evolution and relationships without relying on a stale static diagram. |
| Observability and security | Detailed application, SSO, OIDC, login, failed-attempt, SSH, host, remote-session, threat, system, and error evidence with human descriptions and remediation guidance. | Proven | Tokens, assertions, cookies, private keys, and plaintext secrets are excluded or redacted. |
| Database control | Health, schema audit, migration preview and approval, backups, retention planning, guarded pruning, size caps, vacuum/analyze, and survivability views. | Operational | Destructive SQL is blocked from the safe apply path; maintenance begins with preview and backup. |
What “proven” means here
A feature is not marked proven because a route exists. The evidence path must reach an operational result: the identity is usable, the workstation action is observable, the remote path can be explained, the migration is accounted for, or the security event can be followed by an operator from cause to remediation.