Skip to content

Navigation and administration pages

This reference covers the main navigation, coordination, and administration pages used across analyst and builder work. Most global Settings details are intentionally excluded, except for prompt-template behavior shared with tenant settings. Use it when you want a quick explanation of the pages that help you move around the product rather than produce or review artifacts. It matters because these pages shape how you enter the right workspace, who can access it, and how you check operational context such as AI usage or tenant state. You only need normal access to the product, and most sections are short lookup reads.

Sign-in and sessions

When your session expires, AIKOZO sends you back through sign-in and then returns you to the page you were using. Sessions expire after 30 minutes of inactivity, with a longer absolute cap set by your deployment. The same return flow applies after first-login password setup or a password reset in the identity provider.

If AIKOZO temporarily cannot verify an otherwise active session because the authentication service or network is unavailable, it keeps the current page open, shows a warning, and retries automatically. A sign-in redirect occurs only after the session is conclusively missing, invalid, idle-expired, or past its absolute limit.

Use Logout in the header to end the local session. AIKOZO submits this as a protected action and then continues to the identity provider's sign-out page; opening the logout API address directly does not end a session.

Contextual AI Assistant

When CAP_CONTEXTUAL_ASSISTANT is enabled, an AI launcher appears in the page hero actions near the page help control on supported project, specification, planning, implementation, and artifact pages. It is not shown on settings, profile, tenant administration, AI usage, about, action-pack, or build execution pages. It opens a context-aware assistant for the current page or artifact. The assistant can answer questions from the scoped AIKOZO MCP context and may show structured change proposals for supported artifacts. Assistant answers are rendered as structured Markdown for readable sections, bullets, and count breakdowns.

After each completed turn, the user message shows a muted, single-line Intent label of up to five words. It starts with the main operation, such as Retrieve all, Look up, Search, Summarize, Calculate, Compare, Update, or Assess, and then narrows the scope used by the existing Assistant response and retrieval flow instead of repeating the prompt. A clear single operation stated in English or Slovak is normalized deterministically; compound or negated operation wording stays with the existing Assistant inference. This changes only the feedback label, not routing, and is not a confirmation step. To correct the interpretation, send the correction as the normal next prompt. The copy glyph floats in the bottom-right corner of each message without adding an action row. On a user message it copies the original prompt; on an Assistant message it copies that response. Hovering over a completed message bubble reveals its compact creation date and time in the browser's local timezone.

When Prompt Guru is enabled, the assistant pane includes a prompt-template selector. The default prompt and model for the assistant are managed through the assistant.contextual.chat usage in Settings or Tenant settings.

When the assistant retrieves artifacts, the right pane filters them by the latest user intent and the artifacts named in the latest answer, then lists their user-facing keys or names as links back to the relevant artifact pages.

For clear exact text replacement requests, the assistant can create proposals from scoped artifacts even when the retrieved list only shows previews. The replacement is case-sensitive and applies only to supported scalar text fields, such as requirement final text, use case names or final text, and test case title, description, expected result, or final text.

For specification reorganization requests, the assistant can propose a non-destructive spec restructure. Applying it creates new epics and copies existing requirements, use cases, and test cases into that new structure. The original artifacts are not moved, deleted, renamed, or edited. Copied artifacts start as draft, and missing copied requirement links are shown as warnings.

Proposal cards are summaries. Use Review to open a read-only proposal preview before applying anything. Scalar changes show before/after values or compact status-transition rows. Spec restructure proposals show the proposed target epics with grouped requirement, use case, and test case copies. Applying the proposal happens from the preview footer. The preview uses artifact keys, names, and titles instead of database IDs.

Example questions and commands:

  • Which use cases in this context are in the final state?
  • Which draft test cases already have final text specified?
  • Could you suggest a better structure for the current epic?
  • Set every requirement in this context that already has final text specified to the final state.
  • In requirements whose final text contains Administrator, replace it with administrator.

Clicking an example copies it into the assistant message field so you can review or edit it before sending.

Assistant responses render supported Markdown, including tables. Tables first use compact, content-weighted columns to fit the message width. Hover or focus the table and choose its expand glyph to open a larger preview with vertical scrolling; horizontal scrolling remains available when the content still needs it.

Proposed changes are itemized with before and after values. Nothing is written until you approve a proposal item. Unsupported pages and excluded artifact types remain chat-only.

Settings prompt templates

Global Settings let administrators create, edit, and delete prompt templates stored on the settings singleton. Tenant settings show prompt templates from both the tenant settings document and the global settings singleton. Each prompt row has a Tenant or Global pill. Deleting a tenant prompt removes only the tenant-specific template or override; inherited global prompts stay visible and must be deleted from global Settings.

AI model mappings in Settings and Tenant settings use the same usage labels as AI Usage, including Build execution for build-run apply-patch calls.

Tenant Settings also contains AI Workspace source processing. Its explicit Save action stores the selected tenant's webpage crawl limit, source chunk target and overlap, and knowledge extraction unit size. These values affect new or reprocessed Sources, not Sources that are already ready.

Projects page

Purpose

Use Projects to start work in the correct project, create a new project, and confirm the high-level portfolio you can access.

When CAP_PROJECT_WORKSPACE is enabled, Managers can choose AI Workspace beside AI New for a temporary pre-Project workspace or choose Workspace on an existing Project. See Project Workspace.

Main actions

  • filter the project list by key or name
  • star or unstar projects with the star control, then use the Starred filter to show only your starred accessible projects
  • open a project to continue into specifications or implementations
  • see restricted projects only when you are a manager or assigned as an allowed user
  • create a NewPersonal project when authenticated
  • create a project with New when your role allows it
  • start AI New when CAP_AI_PROJECT_BOOTSTRAP is enabled; non-Managers create a personal draft, while Managers choose personal or collaborative before chat starts
  • for Managers, explicitly include personal projects when they need to inspect private project work
  • refresh the page list

Pop-up modals

  • New personal project: enter key, name, description, and project language
  • New project: enter key, name, description, project language, and access mode
  • Project Setup AI Assistant: Managers choose the target scope first. Non-Managers continue directly with a personal project draft. Chat through project metadata, BIZ/TECH context, and business requirements, then use Create project in the Project summary when the readiness check passes. The draft is temporary, expires after inactivity, and is deleted after the creation job is queued. Each completed user turn also shows its passive single-line Intent label of up to five words beneath the message. The label starts with the main operation and narrows its scope instead of repeating the prompt. Clear single operations in English or Slovak are normalized deterministically, while compound or negated operation wording remains with the existing Assistant inference. This affects the label only, not draft behavior. Send any correction as the normal next prompt; it does not change draft or commit rules. The copy glyph floats in the bottom-right corner of each message without an extra action row. It copies the original prompt or Assistant response. Hovering over a completed message bubble reveals its compact creation date and time in the browser's local timezone.

Project page

Purpose

Use the Project page as the system map for one project. It bridges specification work on the left with implementation work on the right and gives quick access to downstream pages.

When CAP_PROJECT_WORKSPACE is enabled, the Workspace action on the Projects list creates or reopens the single workspace associated with that Project.

Main actions

  • review project description, key, restricted badge, and aggregate counts
  • open project settings
  • promote your personal project with Promote to managed when you own it
  • for Managers, see the human-readable owner name when opening another user's personal project
  • browse project-scoped specification and implementation lists
  • when Planning is enabled for your role and project, browse the project Plans list and review the Planning (Ready) summary counts for Plans, Scopes, Estimates, Risks, and Effort drivers; each Plan row also includes Scope context and the current Minimum Baseline as Baseline
  • open the simplified Workspace for a specification or implementation from the row actions
  • use the Open workspace button on the system-map cards; when there are multiple items, it scrolls to the matching list instead of choosing for you
  • create a new specification
  • create a new implementation
  • create a new Plan container from the project Plans list by selecting a Specification and the Epics that should become Scopes

Pop-up modals

  • New specification: create a specification under the current project
  • New implementation: create an implementation and bind it to a specification
  • New Plan: select a Specification, choose one or more Epics to include as Scopes, then enter Plan key, name, and optional description

Project settings page

Purpose

Use Project settings to review project localization, manage restricted access, and maintain reusable project context text.

Main actions

  • review project language
  • review personal project owner or provenance metadata when it is shown
  • choose the project format preset used by future AI generations
  • set Format Enforcement to Enforce when format validation should block finalization, or Warning Only when format issues should appear as warnings while allowing finalization; new personal projects and existing projects that predate this setting default to Warning Only, while new collaborative projects default to Enforce; source-state gates remain enforced
  • switch project access between unrestricted and restricted
  • assign and remove allowed users on restricted projects
  • browse project context types
  • edit, save, or clear project-scoped context content

Specifications page

Purpose

Use Specifications to browse specification containers across the projects you can access and open the right specification workspace quickly. The cross-project view groups rows by project and each row shows its specification key plus a short description when available.

Main actions

  • filter specifications by key, name, or project
  • use Load more when more matching specifications are available; filtering searches the accessible result set, not only rows already loaded on screen
  • use Workspace on a specification row to open the Specification workspace
  • open the row itself to continue into the advanced Epics page
  • refresh the list through the browser or top-page controls when available

Implementations page

Purpose

Use Implementations to browse implementation containers across the projects you can access and jump into the right implementation workspace. The cross-project view groups rows by project and each row shows the implementation key, linked specification, and a short description when available.

Main actions

  • filter implementations by key, name, project, or specification
  • use Load more when more matching implementations are available; filtering searches the accessible result set, not only rows already loaded on screen
  • use Workspace on an implementation row to open the Implementation workspace
  • open the row itself to continue into the advanced Implementation page

See also

Main actions

Pop-up modals

New implementation appears here when creation is exposed on this page.

Plans page

Purpose

Use Plans to browse first-class planning containers. New Plans are scoped to a Specification and contain one Planning Scope for each selected Epic. A Scope owns the AI-backed assessments for that planned Epic. Assessments extract planning factors in a background job, record the prompt/model used, and update the selected Scope baseline with a rough effort estimate only after a Planner or Admin accepts the assessment. Delivery slicing and delivery-system integration are still out of scope.

Plans require CAP_PLANNING and are visible to Admin and Planner roles.

Main actions

  • filter Plans by key, name, project, Specification, Epic Scope, or lifecycle status
  • open a Plan overview page
  • from a Plan detail page, edit name and description; editing an accepted or superseded Plan reopens it as draft
  • add a missing Epic as a Scope when the Epic belongs to the Plan's Specification
  • open a Planning Scope page and generate or regenerate an AI-backed assessment for it
  • open Estimation Profiles on the Tenant page to view the deterministic profile versions used by Planning assessments
  • open Delivery Role Profiles on the Tenant page to view the deterministic role weights used by Role Allocation
  • review the latest generated assessment, add review notes, optionally override the estimate with justification, and accept one assessment as the current Scope planning baseline
  • delete a Plan after confirmation from the Plans list or the project Plans list
  • inspect accepted baseline state, informational freshness warnings, assessment history, timeline, estimation profile version, and append-only version history

Pop-up modals

  • Edit Plan: update name and description; non-draft Plans are reopened as draft when saved
  • Add Scope: add another epic-derived Scope to the Plan
  • Delete on a Scope: permanently remove that Scope together with its assessments, allocations, lineage links, and derived planning outputs. The confirmation lists the affected resources. Deletion is blocked while related background work is running or while applied Implementation Features still depend on the Scope; delete those Features first. Source Epics and their Requirements, Use Cases, and Test Cases are not deleted.

Plan detail page

The Plan detail page shows the Plan identity and context path: Project, Plan, and the Scopes in the Plan. The context tree links Project, Plan, and Scope rows to their respective pages.

  • Scopes lists Epic-derived Scopes with Full/Active ranges, active/deferred counts, accepted assessment version, allocation state, and freshness. Use the name filter to narrow the visible Scope list. The compact tab control sorts Scopes by oldest, newest, or key and preserves the selection in the URL. Select a Scope row to open it; the only explicit row action is Delete for planners and administrators, which first shows the deletion impact.
  • Minimum Baseline generates immutable deterministic revisions from current accepted dual Scope assessments and canonical Scope Item splits; accepted Specification Allocation is optional. The tab shows Full Scope, Active Scope, Minimum Baseline, Planned reduction, reconciliation buckets and residual, freshness, compact classification counts, and AI-assisted Savings Opportunities. Use Generate to queue indicative AI saving candidates for the current Minimum Baseline as a background job. Track the job in Background jobs. The backend validates every suggestion and calculates indicative saving only from existing allocation data. Decision-needed opportunities can still show an indicative value when the affected artifact has an allocation estimate. Suggestions do not delete or mutate Specification artifacts. When a suggestion maps safely to Planning Scope items, Defer all stores planning-only deferral decisions and marks the opportunity applied without rewriting the immutable source Minimum Baseline.
  • Design verification checks the current Minimum Baseline against the final Implementation Design and selected Patterns. The tab generates, reviews, accepts, supersedes, and refreshes Design-informed Confidence reviews as background jobs.
  • Feature Candidates projects an accepted Minimum Baseline into reviewable Implementation Feature candidates using linked specification artifacts, accepted planning allocations, Design fragments, and selected or allowed Patterns. Generation is queued as a background job and can be tracked in Background jobs. Candidate cards stay concise; open a candidate to review risks, decisions, included scope, required dependencies, traceability, Design fragments, and Patterns on the Feature Candidate detail page. Accepted proposals can be applied only to a new Implementation or an existing Implementation without Features; populated Implementations are protected from accidental merge.
  • Remaining Scope shows projection coverage after Feature Projection apply. It compares Plan Scope lineage with created Feature traceability for Requirements, Use Cases, Test Cases, and effort where allocation estimates exist. Planner/Admin users can create Extensions from selectable remaining or deferred artifacts, generate Extension Feature Candidates, and apply accepted Extension proposals to a new, empty, or same-Plan traceable Implementation.
  • Versions shows the append-only Plan version history

The selected Plan detail tab is reflected in the page URL, so reloading or sharing the link opens the same tab.

The Plan foundation section is intentionally not shown on the Plan detail page. Edit or delete a Plan from the Plans list or the project Plans list after confirmation. Legacy epic-scoped Plans are view-only on the detail page. Superseding a Minimum Baseline is not deletion; old baselines remain audit records.

Planning Scope page

The Planning Scope page owns assessment work for one Epic inside a spec-scoped Plan. The context tree sits above the tabs, with a reserved semantic-search slot for future Planning search. The tabs are Overview for Scope Coverage with foundation details, accepted baseline summary, source Epic, and planning coverage counts; Assessment for the latest generated assessment, review decisions, drivers, missing information, and assessment history; Scope Items for the UC/fallback RQ breakdown; Allocation for Specification Allocation; Roles for Role Allocation; and Timeline for filterable auditable activity with expandable event details.

The selected Planning Scope tab is reflected in the page URL, so reloading or sharing the link opens the same tab.

Scope Coverage combines the Scope description and accepted Scope Estimate summary with source Epic, primary planning item count, Requirement/Use Case coverage, fallback Requirements, and Test Case evidence for the Scope. Refresh Coverage re-derives the covered artifact summary from the Scope source Epic; Admins and Planners can refresh it, while Planning readers can inspect the summary.

The Scope Items tab is populated from the latest generated assessment. It lists each primary Use Case, plus fallback Requirements that are not linked to a Use Case. The summary states this row-selection behavior, while the table focuses on Active/Deferred state, decision provenance and reason, canonical Full and Active effort, UI/backend/data/integration/security/test factor levels, and evidence. Each item uses a two-row group: its label and Action span both rows, while all six factors share a wide merged cell in the second row. This keeps the table within the page without horizontal scrolling. Scope item values link back to the source Use Case or fallback Requirement detail page. The compact tab control cycles through assessment order, reverse assessment order, and key order and preserves the selection in the URL. Admins and Planners can hover a factor pill and click its left or right half to decrease or increase that factor level between none, low, medium, and high. Each change recalculates only that item's canonical contribution and rolls the delta into the Full and Active Scope estimates; it does not redistribute the previous total across other items. Existing allocations are marked stale for audit but remain usable. Admins and Planners can Defer or Restore scope items from a reason-required modal; these actions update only the Planning Scope overlay and leave source Specification artifacts unchanged.

Generate Assessment queues background AI generation. While queued or running, the page polls for the latest status and the shared Background jobs popover shows the queued Planning Scope assessment job. A completed assessment becomes reviewable but does not update the Scope baseline until a Planner or Admin accepts it. Accepting an assessment makes it the current planning baseline for that Scope and recomputes the parent Plan rollup. The parent Plan becomes accepted only when every active Scope has an accepted baseline. Previously accepted assessments for the same Scope are superseded. Overrides preserve the generated estimate and require a justification. The displayed estimation profile key and version identify the deterministic profile used for the assessment. When available, the page also shows the stored profile snapshot name and whether that snapshot was system or custom. Accepted estimates are planning baselines, not delivery commitments. A failed assessment remains in history for audit but cannot become the baseline.

Role Allocation distributes each canonical active Scope Item contribution across its non-none factors, then allocates each factor bucket only to eligible delivery roles using the Plan's Delivery Role Profile. A zero test-factor bucket therefore produces no Tester allocation. It is deterministic and has no equal fallback for missing or all-none factor data. Generated role allocations store the profile snapshot and factor allocation evidence, then reconcile min, most likely, and max totals back to the accepted Scope estimate. Admins and Planners can generate, accept, supersede, and regenerate role allocations. Planners can inspect profile weights; Admins manage custom profile versions and tenant defaults on Tenant. Role Allocation lives on the Roles tab and can be exported as CSV. The factor-to-role effort matrix exposes each factor bucket as a row, each allocated role as a column, and the corresponding contribution in each cell. The Min, Most likely, and Max option buttons above the tables switch both the matrix values and the single Estimate column in the Delivery Role table. The CSV contains the same bucket totals, eligibility, and role contributions.

Specification Allocation selects Full or Active basis (Active by default) and distributes it across linked specification artifacts. It is not an independent estimate for each Requirement, Use Case, or Test Case. The default target is Use Cases when they exist, then Requirements, with Test Cases available when linked. Generated allocations reconcile their min, most likely, and max totals back to the accepted Scope estimate; small rounding is handled by applying the residual to the final item. Admins and Planners can generate, accept, supersede, and regenerate allocations. Allocation artifact values link to their source detail pages, show trimmed final text beside the effort split, and include factor effort buckets across UI, backend, data, integration, security, and test. The buckets use the same canonical Scope Item low/medium/high decomposition as Role Allocation and preserve the item total after rounding. Specification Allocation lives on the Allocation tab. Allocation exports include those factor rows in CSV. Empty states distinguish whether an assessment must be accepted first or whether no allocation has been generated yet. Treat allocations as planning guidance for audit and review, not as delivery commitments.

Tenant Estimation Profiles tab

Estimation Profiles control how Planning turns extracted factors into rough effort estimates in person-days or person-hours. The tab is available from Tenant. Profiles are deterministic configuration, not AI factor extraction prompts. Admins and Planners can view available profile versions and select one when creating or editing a Plan. The profile marked Default is preselected for new Plans, but each Plan still stores its concrete profile reference. Admins can duplicate an existing profile, set a default profile, edit Key, Name, and Description from the profile list, edit the selected custom profile unit and rules directly in the tab, save changes as a new version, or delete profiles that are not referenced by Plans. Scope ranges are interpreted in the selected unit; changing the unit does not convert the stored range numbers. The built-in system profile is an internal fallback and is not managed in the tab; at least one tenant profile must remain. Deleting the current Default profile moves Default to another remaining profile.

Future assessments use the profile associated with the Plan. Existing assessments keep the profile key, version, and snapshot captured at generation time, so their meaning does not change after profile edits.

Tenant Delivery Role Profiles tab

Delivery Role Profiles control how Planning distributes an accepted assessment estimate across delivery roles. The tab is available from Tenant next to Estimation Profiles. The built-in delivery roles and system profile are read-only in V1. Admins and Planners can view roles, role weights, the tenant default marker, factor adjustments, and the effective normalized percentage for every factor, level, and eligible role. These derived percentages show the saved profile result after global role weights and additive adjustments are combined; they are not separately persisted configuration. Admins can duplicate a profile to create a custom tenant profile, edit numeric role weights and adjustments, set a custom profile as the tenant default, delete custom profiles that are not referenced by Plans, and save changes as a new version. Profile key, name, and description are edited from the profile row Edit action; profile deletion is also a row-level action.

Use the tab in this order:

  1. Select a profile to inspect its saved configuration. Built-in profiles are read-only; duplicate one when you need an editable custom starting point.
  2. Set Base Role Weight values for the normal allocation preference. These are relative values, not percentages. Their overall sum has no standalone meaning: it is neither 100% nor a total effort value.
  3. Use Additive Weight Adjustment only when one Planning Factor and Factor Complexity Level should change the starting weight of the listed Affected Delivery Role.
  4. Save the profile, then verify Normalized Delivery Role Shares in the read-only effective table. Set the profile as Default only when it should be preselected for new Plans.

For each factor and level, Planning uses only delivery roles eligible for that factor. A role's combined effective weight is its base role weight plus the listed additive adjustment, with negative results limited to zero. Planning then divides each positive effective weight by the sum of all eligible positive weights, producing normalized shares that total 100%. The effective table is a derived preview of the saved profile and refreshes after saving; it is not a second set of editable configuration values. Because adjustments are additive, the scale of the base weights matters: multiplying every base weight without also scaling the adjustments changes how strongly those adjustments influence the final shares.

Factor Complexity Level is the low, medium, or high complexity classification assigned to that factor on a Scope Item; it is not confidence. Confidence describes the quality of the evidence behind an assessment. A factor classified as none contributes no effort to Role Allocation.

Role Allocation consumes only the UI, Backend, Data, Integration, Security, and Test effort factors. Ambiguity records how unclear or incomplete the expected behavior, boundaries, dependencies, or acceptance evidence are. Reuse potential records the opportunity to reuse existing assets. Both are assessment signals rather than role-allocation effort buckets, so their values are not shown or editable in this profile tab.

Role Allocation stores the delivery role profile key, version, and snapshot with each allocation set. Future Role Allocations use the Delivery Role Profile associated with the Plan. Changing the tenant default only changes the preselected profile for new Plans; existing Plans and allocation history keep their captured profile references, snapshots, and reconciliation data.

AI Usage page

Purpose

Use AI Usage when you want to understand what is happening with AI usage right now, or during a specific reporting period. It helps you answer common operational questions such as which feature drove usage, whether costs are moving up, and whether the tenant has moved beyond the included monthly budget. You do not need to prepare anything before opening the page, and most checks take only a minute or two. This page is for monitoring, not artifact editing.

Main actions

Most people use this page for two kinds of checks: short usage reviews and monthly billing reviews. For example, if a team asks why costs look higher this week, you can switch the range, look at the feature and model breakdowns, and then compare that with the billing state for the current UTC month.

  • switch the reporting range
  • set a custom date range
  • refresh the dashboard
  • inspect estimated cost over time, call and token usage, feature breakdown, model breakdown, and recent events with date and time
  • review tenant AI billing for the selected UTC billing month
  • download a CSV usage report aggregated by day, project, and feature for the selected UTC billing month, including each project's key and name
  • move between UTC billing months with previous, next, and current month controls
  • inspect included budget progress as included budget used versus monthly budget
  • review whether premium billing is active for the selected month
  • inspect remaining included budget or the additional amount charged for premium requests
  • review premium request count, premium charge, and billable spend

About page

Purpose

Use About to confirm what is deployed in the current environment.

Main actions

  • review the current application version and edition
  • inspect effective feature flags and their descriptions

Tenant page

Purpose

Use Tenant for tenant-scoped administration, visibility into current authenticated users, tenant user management, tenant-specific pattern management, Planning estimation profile management, and delivery role profile management.

  • Builder flow: step 5a when execution and pattern setup depends on tenant administration

Main actions

  • review current tenant details
  • for Managers, use Organization evidence to add material through the same composer pattern as Project Workspace Sources: Add files opens a drag-and-drop, multi-file picker with upload progress, including Excel .xlsx workbooks whose tabs and atomic rows are preserved, while Add webpage and Add text open focused forms. The material runs through the existing Source pipeline. Each evidence card shows processing progress, file type, updated time, Pages, Sections, Blocks, links, Concepts, and Assertions in the same style as AI Workspace Sources. Structure opens the same hierarchical Source inspector used by AI Workspace, while Knowledge opens the same searchable Concepts, Assertions, evidence excerpts, and Local graph panes. Retry processing, replace or delete evidence, and rename its human-readable title. Adding a file whose name already exists opens the standard AIKOZO confirmation pane; confirming replaces the existing content, removes its extracted structure, embeddings, and knowledge-graph data, and recreates those derived data from the new file
  • independently make extracted information from a fully ready Source available with Available to AI Assistant and Available to AI Workspace Assistant. These are selectable button cards rather than checkboxes. Both are off by default; content replacement turns both off, while a title-only edit preserves them. Availability requires ready Source processing, vectors, structural graph, current Project Knowledge extraction, and its graph projection
  • understand that Assistants automatically search the available normalized excerpts, structural context, and Project Knowledge. The original uploaded documents are not supplied to an Assistant, Workspace users do not select tenant documents, and unavailable extracted information remains invisible
  • browse tenant users, their current tenant roles, status, and last active time; filter the list by user name and use Load more when more than 20 users match
  • for Manager users, create a tenant user with: username, email, first name, last name, temporary password, and assigned roles
  • for Manager users, validate new-user input before submission: username length and tenant uniqueness, email format, password complexity, and password confirmation
  • for Manager users, deactivate tenant users without deleting them
  • manage tenant format presets used by project-level AI prompt parameters, duplicating an existing preset when another preset is needed; preset names are limited to 16 characters
  • review the tenant OpenAI timeout, review AI model mappings inherited from global settings, enter tenant-specific model overrides when needed, and reset an override back to the inherited global model
  • delete a format preset after confirmation; at least one preset must remain, and presets used by projects must be moved before deletion
  • understand that preset changes affect future AI generations; past AI runs keep their stored prompt history
  • view deterministic Planning estimation profiles; Admins can duplicate, edit, version, and delete custom profiles that are not referenced by Plans
  • view deterministic Delivery Role Profiles; Admins can duplicate, edit, set defaults, delete, and version custom profiles used by future Plans
  • browse shared patterns
  • create, clone, edit, and remove tenant patterns

Pop-up modals

  • New tenant user: create a new tenant-scoped user, assign one or more roles, and require a password change on first sign-in
  • Edit tenant pattern: create or edit a tenant-scoped pattern definition

Profile page

Purpose

Use Profile to review your identity details, inspect claims from the current access token, switch UI language and theme, manage encrypted Personal Access Tokens, and manage saved AI quick phrases.

Main actions

  • review user details
  • use the left navigation tree to switch between User details, Security tokens, and Architecture workspace phrases
  • change the UI language
  • change the UI theme between Dark and Light
  • show or hide token-derived claims
  • store, replace, or remove named masked Personal Access Tokens for JIRA, GitHub, and GitLab; mark one token per provider as default for shared Spec Connections; stored token values are not shown again
  • switch between Architecture workspace phrases tabs for modules, entities, values, processes, events, policies, components, interfaces, and ADRs
  • mark saved phrases as favorite or delete them

Security token defaults

Security tokens are stored per authenticated user and per tenant. A token name such as sync_bot is only a label that lets you select the token on personal Spec Connections or Delivery targets. The default marker is a separate attribute shown as a pill next to one saved token per provider.

AIKOZO keeps exactly one default token for each provider when at least one token exists:

  • the first token you save for a provider becomes default automatically
  • Make default moves the default marker to that saved token
  • when you delete the default token and another token for the same provider remains, AIKOZO marks one remaining token as default
  • token values are masked after save and are never shown again

This default marker matters for shared Spec Connections. A shared Spec Connection stores provider routing such as JIRA project or GitHub repository, but it never stores a Personal Access Token and never uses the token of the user who created the connection. When you validate, import, or run Sync SPEC with a shared connection, AIKOZO looks up your own token marked default for that provider and performs the provider call as you. If your profile has no default token for the provider, the shared connection remains visible but unavailable for provider actions until you save or mark a default token.

Personal Spec Connections use the selected token name from your profile and are visible only to you. Use this mode when the connection itself should remain private or when it should use a specific named token instead of your provider default.

JIRA token setup

AIKOZO uses encrypted JIRA tokens stored per user profile when it validates Spec Connections, imports source issues, and syncs Requirements or Use Cases downstream. Personal Spec Connections use the selected token name. Shared Spec Connections always use the current user's JIRA token marked default, so every user who works with a shared connection needs one usable default token for that provider. Saved tokens are masked after save; the full token value is not shown again.

For JIRA Cloud:

  1. Open the Atlassian API tokens page: https://id.atlassian.com/manage-profile/security/api-tokens.
  2. Select Create API token or Create API token with scopes.
  3. Name the token for AIKOZO, choose an expiration date, and create it.
  4. Copy the token immediately. Atlassian does not show the token again.
  5. In AIKOZO, open Profile > Security tokens, choose a secret name such as jira_sync, paste the value as <atlassian-email>:<api-token>, for example analyst@example.com:token. Use Make default if this token should be used by shared JIRA Spec Connections. This lets AIKOZO use JIRA Cloud basic authentication against the JIRA site URL configured on the Spec Connection.

JIRA Cloud uses Atlassian account API tokens for this flow. If your team calls these PATs, use the API token page above rather than looking for a Personal access tokens menu inside the JIRA Cloud product.

For JIRA Data Center or Server:

  1. In JIRA, open your avatar menu, choose Profile, and then Personal access tokens.
  2. Select Create token, give it a clear name, optionally set an expiration, and create it.
  3. Copy the token immediately.
  4. In AIKOZO, open Profile > Security tokens, choose a secret name such as jira_sync, and paste the raw PAT value only. Use Make default if this token should be used by shared JIRA Spec Connections. AIKOZO sends Data Center PATs as Bearer tokens.

Atlassian's Data Center PAT documentation is available at https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html.

The JIRA account behind the token must be able to browse the target project and create or edit issues in that project. If your organization blocks token creation or restricts scoped tokens, ask a JIRA or Atlassian administrator for a token policy and permission check.

GitHub and GitLab token setup

AIKOZO also uses GitHub and GitLab tokens stored in Profile > Security tokens when validating those Spec Connections, importing source issues, and syncing Requirements or Use Cases to downstream issues. Personal Spec Connections use the selected token name. Shared Spec Connections always use the current user's provider token marked default. Store a token that can read the configured repository or project and create or edit issues before using a shared or personal connection. GitHub connections use the configured owner/repository; GitLab connections use either the project ID or the encoded repository path such as group/project.

For GitHub repository-backed builds, use a token owned by an account that can push branches and open pull requests in the target repository. Recommended GitHub fine-grained PAT repository permissions are:

  • Metadata: read
  • Contents: read and write
  • Pull requests: read and write
  • Issues: read and write, when the same token is also used for issue sync
  • Workflows: write, when AIKOZO may create or update files under .github/workflows/

For a classic GitHub PAT, use repo for private repositories or public_repo for public repositories. Add the classic workflow scope whenever generated build output can create or update GitHub Actions workflow files under .github/workflows/. Without that workflow permission, GitHub rejects the push with an error that the token cannot create or update workflow files.

After creating or replacing the token, save it in Profile > Security tokens. For personal GitHub or GitLab Spec Connections and Delivery targets, select the saved token name on the connection or target. For shared Spec Connections, use Make default on the token that should be used for your account. Run the connection or target validation before starting repository-backed builds.