coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add user-engine evaluation readiness pack

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-23 05:18:54 +02:00
parent cab14fdd7e
commit 4e4cec6555
34 changed files with 1597 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
infospace/evaluations/user-engine/consumer-workplan-brief.md Normal file
View File

@@ -0,0 +1,61 @@
---
id: evaluation/user-engine/consumer-workplan-brief
title: User Engine Consumer Workplan Brief
status: candidate
consumer: user-engine
evaluation_pack: evaluation/user-engine
---
# User Engine Consumer Workplan Brief
## Purpose
Use this brief as the seed for a user-engine repo workplan. The adoption and
implementation workplan belongs in the user-engine repository, not in
InfoTechCanon.
## Goal
Evaluate user-engine against InfoTechCanon before integration as the
user-management capability.
## Canon Inputs
- `infospace/evaluations/user-engine/evaluation-pack.yaml`
- `infospace/evaluations/user-engine/questions.yaml`
- `infospace/evaluations/user-engine/interface-card-expectations.yaml`
- `infospace/evaluations/user-engine/small-saas-alignment.yaml`
- `infospace/agent/templates/canon-interface-card.template.yaml`
- `infospace/examples/consumer-purpose-portfolio.yaml`
## Workplan Tasks For User Engine
1. Complete a Canon Interface Card for user-engine.
2. Export or describe entity mappings for user, account, actor, subject,
principal, tenant, team, role, access role, policy, control, evidence, and
lifecycle work.
3. Export or describe edge mappings for membership, tenant scope,
authentication, subject evaluation, role assignment, policy governance,
control implementation, evidence, and task creation.
4. Answer the canon evaluation question set by domain.
5. Evaluate small-saas alignment using Ada Admin, Acme, Globex, tenant
isolation policy, namespace-per-tenant control, and access review evidence.
6. Record purpose fit, gaps, scope pressure, and requested evolution.
## Expected Outputs
- completed interface card,
- answered question set,
- entity and edge mapping export,
- evidence bundle or explicit evidence gaps,
- small-saas alignment notes,
- list of user-engine changes,
- list of canon evolution requests.
## Non-Goals
- Do not change InfoTechCanon from the user-engine workplan without a canon-side
evolution request.
- Do not treat this evaluation as integration approval.
- Do not collapse implementation-specific names into canon concepts without a
mapping and rationale.

65
infospace/evaluations/user-engine/evaluation-pack.yaml Normal file
View File

@@ -0,0 +1,65 @@
id: evaluation/user-engine
title: User Engine Canon Evaluation Pack
status: candidate
consumer: user-engine
purpose: Evaluate user-engine against InfoTechCanon before integration as the user-management capability.
created_by_workplan: ITC-WP-0007
evaluation_mode: pre-integration
canon_anchors:
- model/organization
- model/access-control
- model/governance
- model/data
- model/security
- model/task
- model/purpose-demand-extension
- profile/small-saas
- standard/caring
pack_components:
questions: evaluations/user-engine/questions.yaml
interface_card_expectations: evaluations/user-engine/interface-card-expectations.yaml
small_saas_alignment: evaluations/user-engine/small-saas-alignment.yaml
consumer_workplan_brief: evaluations/user-engine/consumer-workplan-brief.md
evaluation_surfaces:
- user identity and account lifecycle
- actor, subject, and principal distinctions
- organization roles and access roles
- tenant, team, and membership boundaries
- permission and entitlement traces
- policy, control, evidence, and access review traces
- data handled by user management
- security controls around credentials, sessions, and privileged access
- tasks created by onboarding, review, remediation, and deprovisioning
- consumer purpose, demand signal, purpose fit, and scope pressure
readiness_gates:
- id: gate/user-management-core
title: Core user-management concepts are mapped.
required: true
expects:
- User, Account, Actor, Subject, Principal, Team, Tenant, Role, AccessRole, Policy, Control, Evidence.
- id: gate/access-trace
title: Access grants are traceable to scope, policy, control, and evidence.
required: true
expects:
- Each privileged grant identifies role, subject or principal, resource scope, tenant boundary, governing policy, and evidence.
- id: gate/governance-evidence
title: Governance evidence exists before integration.
required: true
expects:
- Access review, exception, approval, and remediation records are available or explicitly marked as gaps.
- id: gate/purpose-fit
title: Consumer purpose and producer fit are explicit.
required: true
expects:
- user-engine declares intent, scope, purposes, demand signals, current fit, and requested evolution.
output_expectations:
- completed Canon Interface Card for user-engine
- answered evaluation question set
- entity and edge mapping export
- small-saas alignment notes
- evidence bundle or explicit evidence gaps
- consumer-side workplan created in the user-engine repo
non_goals:
- Refactor user-engine in this repo.
- Decide user-engine implementation details in this repo.
- Treat evaluation success as automatic integration approval.

148
infospace/evaluations/user-engine/interface-card-expectations.yaml Normal file
View File

@@ -0,0 +1,148 @@
id: evaluation/user-engine/interface-card-expectations
title: User Engine Canon Interface Card Expectations
status: candidate
consumer: user-engine
evaluation_pack: evaluation/user-engine
expected_consumer_fields:
repo: user-engine
domain: user-management
intent: Evaluate and later integrate user-management capability against InfoTechCanon.
scope:
- user identity
- accounts
- tenants
- teams
- memberships
- roles
- access decisions
- access reviews
- governance evidence
purposes:
- id: user-engine/user-management-evaluation
use_case: Compare user-engine entities and access behavior with InfoTechCanon models and small-saas profile expectations.
consumer_need: Clear distinction among identities, actors, principals, subjects, roles, grants, policies, controls, evidence, and lifecycle work.
demand_signals:
- user-engine will be assessed before integration.
- user-engine needs a canon-side conformance question set.
expected_canon_surfaces:
implemented_profiles:
- profile/small-saas
consumed_artifacts:
- model/organization
- model/access-control
- model/governance
- model/data
- model/security
- model/task
- model/purpose-demand-extension
- standard/caring
consumed_concepts:
- Actor
- Subject
- Principal
- User
- Team
- Tenant
- Organization Role
- AccessRole
- Permission
- Entitlement
- ResourceScope
- Policy
- Control
- Evidence
- AccessReview
- ConsumerPurpose
- PurposeFit
- EvolutionRequest
expected_entities:
- id: user
canon_anchor: model/organization
expectation: Represents a human or service user without collapsing into authenticated principal.
- id: account
canon_anchor: model/access-control
expectation: Represents login or system account bound to a user, actor, or principal.
- id: principal
canon_anchor: model/access-control
expectation: Represents authenticated identity used in an authorization decision.
- id: subject
canon_anchor: model/access-control
expectation: Represents entity evaluated by policy, possibly a user, principal, group, or service account.
- id: tenant
canon_anchor: model/organization
expectation: Represents customer or organization boundary used for membership, data, and access scope.
- id: team
canon_anchor: model/organization
expectation: Represents operational group, not an access role.
- id: organization-role
canon_anchor: model/organization
expectation: Represents responsibility or position.
- id: access-role
canon_anchor: model/access-control
expectation: Represents permission bundle or access capability.
- id: policy
canon_anchor: model/governance
expectation: Governs access or lifecycle behavior.
- id: control
canon_anchor: model/security
expectation: Implements or enforces a policy or objective.
- id: evidence
canon_anchor: model/observability
expectation: Supports review, control, access, or integration claims.
expected_edges:
- type: member_of
source: user
target: team
expectation: User or actor belongs to team.
- type: belongs_to_tenant
source: user
target: tenant
expectation: User or account is scoped to a tenant when applicable.
- type: authenticates_as
source: account
target: principal
expectation: Account produces or binds authenticated principal.
- type: evaluated_as
source: principal
target: subject
expectation: Principal is evaluated as policy subject.
- type: assigned_role
source: subject
target: access-role
expectation: Subject receives access role within explicit scope.
- type: scoped_to
source: access-role
target: tenant
expectation: Access role or grant declares resource or tenant scope.
- type: governed_by
source: access-grant
target: policy
expectation: Grant traces to policy or rule.
- type: implemented_by
source: policy
target: control
expectation: Policy is enforced by a control.
- type: evidenced_by
source: access-grant
target: evidence
expectation: Grant, review, or control has evidence.
- type: creates_task
source: evaluation-gap
target: task
expectation: Gap creates work only after triage and commitment.
evidence_required:
- completed Canon Interface Card
- entity and edge mapping export
- access grant trace
- tenant-scoped role or permission example
- access review example
- policy/control/evidence trace
- data object inventory for user-management data
- user lifecycle task or request examples
- explicit integration gaps and requested evolution
validation_expectations:
commands:
- PYTHONPATH=src python3 -m info_tech_canon validate
- PYTHONPATH=src python3 -m info_tech_canon profile validate small-saas
known_gaps_allowed: true
gap_rule: A gap is acceptable only when recorded with purpose fit state, owner, and proposed disposition.

135
infospace/evaluations/user-engine/questions.yaml Normal file
View File

@@ -0,0 +1,135 @@
id: evaluation/user-engine/questions
title: User Engine Canon Evaluation Questions
status: candidate
consumer: user-engine
evaluation_pack: evaluation/user-engine
question_domains:
- id: organization
title: Organization
canon_anchors:
- model/organization
- profile/small-saas
questions:
- id: org-001
question: Which user-engine records map to Person, User, Actor, Agent, Team, Tenant, Role, Membership, Assignment, Responsibility, Authority, and Accountability?
expected_evidence:
- entity mapping table
- examples for human users and service users
- id: org-002
question: How does user-engine distinguish Actor, Subject, and Principal in authentication and authorization contexts?
expected_evidence:
- concept mapping
- access-decision trace
- id: org-003
question: How are tenant membership, team membership, ownership, and delegated administration represented?
expected_evidence:
- tenant/team membership export
- owner or administrator assignment records
- id: access-control
title: Access Control
canon_anchors:
- model/access-control
- standard/caring
- profile/small-saas
questions:
- id: ac-001
question: Which user-engine concepts map to AccessRole, Permission, Entitlement, ResourceScope, RoleBinding, AuthorizationDecision, and AccessPolicy?
expected_evidence:
- entity mapping table
- role and permission examples
- id: ac-002
question: Can every privileged access grant identify subject or principal, access role, resource scope, tenant boundary, governing policy, and evidence?
expected_evidence:
- grant trace
- tenant-scoped role binding example
- id: ac-003
question: How are Organization Role, AccessRole, and CARING canonical role kept distinct?
expected_evidence:
- distinction notes
- CARING role classification examples
- id: governance
title: Governance
canon_anchors:
- model/governance
- standard/caring
questions:
- id: gov-001
question: Which user-engine records carry policy, control, review, approval, exception, waiver, evidence, and decision semantics?
expected_evidence:
- governance mapping table
- review and approval examples
- id: gov-002
question: What evidence shows that access grants are reviewed, approved, remediated, or expired?
expected_evidence:
- access review records
- remediation or exception records
- id: gov-003
question: Who has decision rights for accepting, rejecting, or deferring integration gaps?
expected_evidence:
- decision authority statement
- accountable owner
- id: data
title: Data
canon_anchors:
- model/data
- profile/small-saas
questions:
- id: data-001
question: Which user-engine data objects contain identity, account, tenant, membership, role, permission, credential, or audit data?
expected_evidence:
- data object inventory
- processing purpose notes
- id: data-002
question: How are tenant partitioning, retention, residency, lineage, and processing purpose represented for user-management data?
expected_evidence:
- data boundary description
- tenant partition example
- id: security
title: Security
canon_anchors:
- model/security
- model/access-control
- profile/small-saas
questions:
- id: sec-001
question: How does user-engine represent credentials, sessions, privileged access, MFA or equivalent assurance, and secret handling boundaries?
expected_evidence:
- security concept mapping
- privileged access scenario
- id: sec-002
question: Which incidents, findings, or alerts can be linked to users, principals, tenants, controls, and evidence?
expected_evidence:
- incident linkage example
- finding or alert export
- id: task
title: Task
canon_anchors:
- model/task
- profile/small-saas
questions:
- id: task-001
question: Which onboarding, access request, review, remediation, deprovisioning, and integration-gap items map to WorkItem, Task, Request, ReviewTask, ApprovalTask, RemediationTask, or ChangeTask?
expected_evidence:
- lifecycle task examples
- task state mapping
- id: task-002
question: How does user-engine distinguish captured requests from committed implementation or remediation tasks?
expected_evidence:
- task commitment mapping
- backlog or issue examples
- id: purposes
title: PURPOSES
canon_anchors:
- model/purpose-demand-extension
- pattern/intent-scope-purposes
questions:
- id: pur-001
question: What consumer intent, scope, purposes, use cases, demand signals, and consumer needs does user-engine declare for canon integration?
expected_evidence:
- completed Canon Interface Card
- consumer purpose statement
- id: pur-002
question: Which purpose fit state applies to user-engine now, and which gaps create scope pressure or evolution requests for InfoTechCanon?
expected_evidence:
- purpose fit review
- requested evolution list

58
infospace/evaluations/user-engine/small-saas-alignment.yaml Normal file
View File

@@ -0,0 +1,58 @@
id: evaluation/user-engine/small-saas-alignment
title: User Engine Small SaaS Alignment Lens
status: candidate
consumer: user-engine
evaluation_pack: evaluation/user-engine
profile: profile/small-saas
alignment_goal: Use small-saas as the concrete tenant-aware SaaS lens for user-management evaluation.
profile_requirements:
- required_concept: tenant
small_saas_artifacts:
- small-saas/tenant/acme
- small-saas/tenant/globex
user_engine_expectation: User-engine can represent tenant boundaries and bind users, accounts, roles, and evidence to them.
- required_concept: user
small_saas_artifacts:
- small-saas/user/ada-admin
user_engine_expectation: User-engine can map users separately from accounts, principals, subjects, and access grants.
- required_concept: team
small_saas_artifacts:
- small-saas/team/platform
user_engine_expectation: User-engine can represent team membership without treating teams as permission bundles.
- required_concept: policy
small_saas_artifacts:
- small-saas/policy/tenant-isolation
user_engine_expectation: User-engine access behavior can trace to governing policy.
- required_concept: control
small_saas_artifacts:
- small-saas/control/namespace-per-tenant
user_engine_expectation: User-engine can show which controls enforce tenant isolation or access boundaries.
- required_concept: evidence
small_saas_artifacts:
- small-saas/evidence/access-review-2026-05
user_engine_expectation: User-engine can provide or link evidence for access reviews and privileged grants.
- required_concept: task
small_saas_artifacts:
- small-saas/task/onboard-tenant
user_engine_expectation: User-engine can identify onboarding, access request, review, remediation, and deprovisioning work.
- required_concept: incident
small_saas_artifacts:
- small-saas/incident/cross-tenant-access-attempt
user_engine_expectation: User-engine can link access incidents or findings to users, principals, tenants, controls, and evidence.
conformance_questions:
- Can Ada Admin's tenant-admin grant for Acme be represented with user, subject, principal, role, tenant scope, policy, and evidence?
- Can Globex remain isolated from Ada Admin unless an explicit grant, scope, and evidence record exists?
- Can tenant isolation policy connect to control evidence and review records?
- Can onboarding a tenant create trackable work without implying that every request is already committed?
- Can any integration gap become an EvolutionRequest instead of an undocumented scope change?
pass_conditions:
- All required small-saas user-management artifacts have matching user-engine entities or explicit gaps.
- Access grants carry tenant scope, role, governing policy, and evidence.
- User, team, tenant, organization role, access role, subject, and principal are not collapsed into one concept.
- Evidence gaps are explicit and produce review or remediation work.
- PURPOSES fields identify current purpose fit and requested evolution.
failure_conditions:
- User-engine cannot distinguish organization roles from access roles.
- User-engine cannot trace privileged access to tenant scope and evidence.
- User-engine treats consumer demand as automatic producer scope.
- User-engine cannot produce a mapping export or completed interface card.