About this environment

About Profile Sentinel

Profile Sentinel analyses SAIP-compatible eSIM profiles. The product workflow (login, profile upload, analysis, findings, report, persistent session, audit trail) is functionally complete; the rule knowledge that drives the analysis progresses through a formal validation lifecycle.

This page consolidates the data-handling rules, the rule-validation lifecycle, and the items that remain on the deferred list. The main user journey deliberately keeps these details out of the way; this page is the authoritative reference.

What this environment is

• An analysis environment for SAIP-compatible profiles using a configured rule pack.
• Operated by named, authenticated users — email plus scrypt-hashed password (Phase 66B). An IP allowlist is available as optional hardening but is not required.
• Backed by a single SQLite store under var/state/ for sessions and audit events (Increment 11 / Increment 11-Consolidated).
• Container-portable — the same image runs locally and in a future hosted demo.

What this environment is not

• Verdicts are diagnostic and the schema CHECK-constrains official_compliance_claim=0 on every persisted row. (At the 2026-05-25 production go-live the image label became org.saip.production_readiness="true" and the production_ready CHECK was relaxed to IN (0,1); the application still persists 0.)
• It is not a path for confidential customer data. Operators must only upload files authorised for internal analysis.
• It is not connected to the standards knowledge base. Standards-source ingestion is a separate, deferred phase.
• It is not a regulated audit-of-record system. Tier-4 deployment will replace the local audit log with a tamper-evident, off-host pipeline.

Rule-validation lifecycle

The rule knowledge base progresses through these states. The current environment runs at the lowest two states.

Until rules reach expert_validated AND active, the analysis output is diagnostic rather than a formal compliance verdict.

Data handling

• Uploads. Files are validated (extension allowlist, size cap, filename sanitisation, path-traversal rejection) and stored under var/state/uploads/<upload_id>/ on the bind-mounted volume. SHA-256 is recorded.
• Canonical envelope. A schema-conformant canonical profile envelope is built per upload and stored under var/state/canonical/<upload_id>.json + the canonical_profiles table.
• Sessions and audit. Every analysis creates a session row in demo_sessions and an event chain in audit_events. The schema CHECK-constrains mock_only=1, test_file_only=1, official_compliance_claim=0 (the production_ready CHECK was relaxed to IN (0,1) at the 2026-05-25 go-live; the application still persists 0).
• Retention. Default SAIP_DEMO_RETENTION_DAYS=0 retains everything. The retention helper is operator-invoked only.
• Backups. The backup helper writes to a local var/state/backups/ directory; no remote target.
• Wipe before any later phase. Before introducing real data, run: rm -f var/state/saip_demo.sqlite3* && rm -rf var/state/uploads var/state/canonical var/state/backups. The schema is recreated on next launch.

Security controls (preserved)

• Loopback-only host edge in the container (127.0.0.1:8000:8000).
• Non-root container user · all Linux capabilities dropped · read-only rootfs · no-new-privileges.
• Account-based authentication (email + scrypt-hashed password) plus signed session cookie when SAIP_DEMO_AUTH_ENABLED=true; an IP allowlist may be configured as additional hardening (optional). Placeholder cookie secrets are rejected at startup.
• Schema CHECK constraints enforce posture at the row level.
• State directory path-safety check refuses paths outside project root / /app / /tmp.

Roles & rule governance

The application uses three roles (MR-M3-03). Each is a distinct internal role identifier — user, supervisor and admin — with the permission boundaries below:

• User (internal id user) — default role. Can sign in, upload SAIP profiles, view diagnostic results and reports, and submit improvement suggestions via the Suggest an improvement form. Users do not access the technical Rule Editor.
• Supervisor (internal id supervisor) — opt-in (an admin promotes a User). Inherits all User permissions PLUS rule governance: the suggestion review queue and the technical Rule Editor (review proposals, request changes, reject, approve, activate, retire, supersede). Supervisors do not administer users, licenses or the active rule set. Cannot approve own proposal.
• Admin (internal id admin) — full platform administration (user lifecycle, invitations, licenses, active rule set, admin console) and rule governance. The deployment-level administrator created by scripts/bootstrap_admin_user.py is an Admin; the env var SAIP_DEMO_RULE_APPROVERS also resolves matched subjects to Admin. Cannot approve own proposal.

Technical rule lifecycle (visible inside the Supervisor-only Rule Editor): new proposals start as Draft, get Submitted for review, may be sent back for Changes requested, then either Approved + Activated, or Rejected. Activation makes the rule available to the diagnostic analysis.

Audit: every action records a governance event (rule_proposal_created, rule_proposal_edited, rule_proposal_submitted, rule_changes_requested, rule_proposal_approved, rule_activated, rule_proposal_rejected, rule_retired, rule_superseded) plus role-denial events (forbidden_rule_action_blocked, self_approval_blocked) in BOTH rule_review_events AND the main audit_events log.

For the full model see docs/rule_editor_governance_workflow.md, docs/rule_lifecycle_model.md, docs/rule_editor_operator_guide.md, and project/tec_rule_governance_strategy.md / project/tec_rule_governance_roles_matrix.md.

User onboarding · admin console · email · license · active rule set (Inc 12C/12D/12E)

The product workflow now supports a realistic operating model:

• Admin console at /admin (Admin only — internal role id admin). Manages user records, role assignments (with reason), invitation creation / resend / revoke, and the local license. Supervisors do not access the admin console (they carry rule governance, not platform administration); User (internal id user) and Supervisor access to admin pages is refused with a 403 + admin_access_denied audit event.
• Invitation workflow: admin issues an invitation; the SHA-256 token hash is stored, never the raw token. Operator follows the link in the invitation email; /invite/accept activates the user record and emits a welcome email. Activation links are built from the configured SAIP_APP_PUBLIC_BASE_URL so they resolve over HTTPS even when the application sits behind a reverse proxy. Default invitation TTL is SAIP_APP_INVITATION_TTL_HOURS (72 h).
• Email abstraction. SAIP_APP_EMAIL_MODE selects the delivery path: smtp (real SMTP relay), file_outbox (operator outbox; no external SMTP), console (development), or disabled. SMTP credentials, when configured, live only in the host-side .env.production (mode 0600) and are never committed. Every generated email is recorded in email_events.
• License / entitlement (local-only). The license is read from a JSON file at SAIP_DEMO_LICENSE_FILE, or a development entitlement is auto-generated when SAIP_DEMO_LICENSE_REQUIRED=false. Feature gating supports upload, analysis, reports, rule_governance, admin_console, audit, licensing. No external license activation; no network call.
• Active rule set integration. Each analysis session captures a deterministic snapshot of the rule set used (rule_set_id + rule_set_version + rule_set_hash + active_rule_count). active rule_drafts with enabled_for_diagnostic_analysis=1 are included in the snapshot for traceability. The compute kernel under app/core/* remains byte-identical between increments; dynamic execution of activated drafts is documented as a Tier-4 deliverable.

See docs/user_onboarding_admin_guide.md, docs/email_notification_model.md, docs/license_entitlement_model.md, docs/active_rule_set_analysis_integration.md.

Current limitations & deferred items

• The standards knowledge base is a separate later phase; ./standards_sources/raw/ remains empty.
• Real ASN.1 / TCA-IPP parsing of binary uploads is reserved for Tier-4 production.
• No automated malware scan on uploads; operator confirmation + extension allowlist + size cap are the demo-tier controls.
• No remote audit forwarding (SIEM / Splunk / Loki); audit retention is local-only.
• Expert validation of rules, severity calibration, fixture coverage and use-case validity will land after the upcoming demo per SC03-D6.