Skip to content

Project Workspace

Project Workspace is a feature-gated discovery area associated one-to-one with a Project. Its dedicated persistence model stays behind the normal Project UI.

There are two entry points:

  • choose AI Workspace next to AI New to open an empty temporary workspace before a Project exists;
  • choose Workspace on an existing Project to create or reopen that Project's workspace.

A temporary AI Workspace expires after 24 hours when abandoned and can be discarded explicitly. Discard workspace uses destructive styling and asks for confirmation before permanently deleting the workspace. Its expiry time is displayed in the browser's local timezone. When Genesis creates its Project, the same workspace becomes the persistent workspace for that Project. A Project cannot have more than one Project Workspace, and a workspace cannot create or attach to more than one Project.

Permissions

Authenticated users with normal Project read access can view a workspace. Managers can create, edit, analyze, review, archive, delete, and promote workspace content. Assistant conversations are private to each user; Sources, Findings, and specification artifact drafts are shared within the tenant.

Source material and limits

You can add PDF, DOCX, Excel .xlsx, HTML, Markdown, and plain-text files, public webpage snapshots, and pasted text. Original uploaded binaries are not retained. The default upload limit is 20 MiB, webpage response limit is 5 MiB, and normalized text limit is 5,000,000 characters. Encrypted or text-empty PDFs are rejected. Archive expansion, PDF page count, parser memory, CPU time, wall time, and concurrent parser work are also bounded; a source that exceeds one of these safety limits is rejected without being imported. Managers choose Add files to open a pane where they can drop one or more files or use Open files to select them with the operating-system file picker. The pane lists the selected files before they are added and, during upload, shows the current file and aggregate byte progress across the selection. Each accepted source also appears in Background jobs as AI Workspace source processing and progresses from queued to running to completed as its worker lifecycle advances. Select that job title to return to the AI Workspace that owns the source. A source becomes Ready only when that processing job has completed successfully.

Source material is shown in the same card style as other application items and is not individually selectable. Most Sources are normalized as an immutable Source version → Page → Section → Block hierarchy. Excel Sources preserve the workbook structure as Source version → Worksheet → Row: each non-empty worksheet row remains one atomic processing and embedding block, including its column coordinates, and is never split into separate cell or partial-row chunks. One stage bar reports the active lifecycle step and fills as structural processing, embeddings, knowledge extraction, and knowledge projection advance. Cards show Section and Block metrics, or Worksheet and Row metrics for Excel. PDF cards also show their reliable physical-page count, while webpage cards show fetched-page and captured-link counts; document cards omit link counts. Completed knowledge extraction adds separate Concept and Assertion metrics. DOCX, HTML, Markdown, and text are flow-based formats: the processor preserves explicit DOCX page breaks and logical Page nodes, but it cannot reproduce layout-driven Word pagination without rendering the original file. Their cards therefore omit a potentially misleading page total, and their structure inspector does not repeat Page 1 on every item. Structure opens a spacious modal pane that lazily expands the hierarchy and captured links. Source actions are stacked in a right-side rail on wider screens and move below the content on narrow screens. Managers can edit the title and content of pasted-text Sources or the title and URL of webpage Sources. A content or URL change stages a new immutable version and temporarily removes that Source from Assistant scope. A failed graph or vector projection can be retried from retained normalized content without uploading the original binary again.

When the Project Knowledge capability is enabled, a separate asynchronous extraction follows successful Source processing. Its Pending, Processing, Ready, and Failed status never changes Source readiness. Extraction uses bounded Source windows and an operation-specific timeout, and the Source stage bar shows completed extraction units. A failed extraction stops and can retry only the knowledge phase; it does not repeat structural graph or embedding work. Validated extraction units are checkpointed after a failure, so a compatible retry resumes those units and re-runs only missing or invalid units; a Source, prompt, model, schema, or unit-boundary change invalidates incompatible checkpoints. Failures appear as a small error glyph instead of expanding the card with technical output. Hover over the glyph for the full details or select it to copy those details to the clipboard. Knowledge opens a read-only Concept and Assertion browser scoped to the Source by default, with an all-Sources scope, evidence navigation, and an on-demand local graph. The Concept list shows approximately eight rows before scrolling so the Local graph remains visible. Evidence opens in a pane above the Knowledge inspector, and Local graph can open in its own fullscreen pane above both. Assertions always link back to supporting Source elements; a failed extraction can be retried without reprocessing the Source.

Webpage ingestion accepts only public HTTP(S) addresses, validates every redirect, sends no cookies or authentication headers, and rejects private, loopback, link-local, reserved, multicast, unspecified, and metadata destinations. Each connection is pinned to the public address that was validated for that request while HTTPS certificate validation continues to use the requested hostname. Semantic header, nav, and footer elements are excluded from extracted text and captured links so repeated page chrome does not enter source processing. The root page is followed to one click of unique same-origin HTTP(S) links only; child pages are never recursively traversed. robots.txt is honored and failure to retrieve it safely closes child traversal while still allowing the root page. The tenant setting Project Workspace crawl page limit controls the total number of pages including the root, from 1 to 100, with a default of 20. To change the limit to 5, an administrator opens Settings, opens the tenant, sets the value to 5 under AI Workspace source processing, and chooses Save. External, denied, capped, non-HTML, failed, and depth-limited links remain visible in the inspector.

The same Tenant Settings section controls the source chunk target (default 800 tokens), chunk overlap (default 80 tokens), and maximum knowledge extraction unit size (default 8,000 characters). Larger chunks and extraction units reduce embedding or extraction calls; smaller values keep retrieval and extraction more focused. Lower overlap reduces embedding volume. Saved values apply only when a Source is processed or reprocessed, so existing ready Sources are unchanged until then.

Grounding and citations

The AI Workspace Assistant is the primary discovery and structure workbench. Its persistent conversation is paired with three contextual views:

  • Discover shows guided questions, exact workspace-state counts, and private pending structure changes;
  • Decide contains the canonical shared Finding and decision inbox;
  • Structure contains the Business and Technology Context drafts, generated Epic/Requirement hierarchy, validation, and promotion controls.

Full workspace opens the same workbench in a centred expanded layout without starting a separate conversation. Its title and Reset/Close actions form a centred horizontal group in the global header so the wider workbench begins immediately below it. The assistant conversation and inspector use an equal 50/50 split except on narrow mobile screens, where they stack. The AIKOZO logo, Help, and authentication controls remain visible. The conversation follows the standard AIKOZO AI Assistant interaction: Enter sends, Shift+Enter inserts a new line, the user message appears immediately, and an animated drafting message remains visible while AI is responding. Clicking a helpful question copies it into the message field so it can be reviewed or edited before sending. The primary Business Context question is What is the purpose of this project from consumer point of view? Before a structure draft exists, this appears as a helpful question alongside grounded prompts for drafting concise Business and Technology Contexts from the Sources. The list also includes Do we qualify to bid for this project call?, which asks the Assistant to compare mandatory requirements and prerequisites from Workspace Sources with people, certificates, skills, and competencies in published Organization evidence. The response cites gate and organization evidence separately, treats missing evidence as unknown rather than failure, and uses a conservative qualifies, does not qualify, conditional, or unknown conclusion. After generation, the Business Context prompt asks the Assistant to review and update the draft around that consumer-purpose question, while the Technology Context prompt checks accepted Findings for unsupported assumptions, missing constraints, and invented technology choices.

Every Source must have both its structural Neo4j graph and Redis vector projection before it becomes ready. For ordinary questions, the assistant retrieves eight semantic seed chunks, expands them through ancestors, adjacent Blocks, containing Sections and Pages, and directly linked fetched Page context, then supplies at most 16 primary evidence chunks and 64 graph nodes/edges. An explicit request to inspect, enumerate, or process every row of a named Excel Source instead uses exhaustive Source retrieval: the Assistant is scoped to that Source, reads every stored atomic row in worksheet order, and verifies that the retrieved count equals the stored count before inference. Complete Workspace Source and Organization evidence retrieval reads stable pages of up to 200 active chunks until the counted total is reached; a missing, repeated, or mismatched page fails explicitly instead of returning a partial catalog. For an Organization-wide enumeration that does not name a Source, every Organization evidence Source represented in the semantic matches is retrieved completely, so a generic summary cannot hide matching records from another Source. The Ask about this Source action and an explicitly named Source remain scoped to that exact Source. There is no lexical fallback: missing dependencies or incomplete selected Sources produce an explicit readiness error. Source content, URLs, and anchor text are untrusted data, so embedded instructions are not followed and a hyperlink proves only that the link exists. Responses render supported Markdown. Tables use compact content-weighted columns in the conversation; hovering or focusing a table reveals an expand glyph that opens a larger, vertically scrollable preview. Validated evidence marks such as [S1] appear beside supported claims. The complete bracketed mark is a button; activating it opens a modal pane with the immutable Source excerpt, checksum, and a readable hierarchy derived from the cited node in the Source knowledge graph. Each label is bound to one exact retrieved Source/chunk pair before the AI call. An answer that references a label without that validated mapping is rejected instead of displaying a broken or ungrounded marker. Source rows show how many Findings cite them and can seed a grounded question. Finding cards expose their own evidence buttons so review does not depend on finding an older conversation message.

Follow-up questions use up to six recent complete user/Assistant turns, bounded to 24,000 normalized characters, to resolve pronouns, corrections, and omitted subjects before Source retrieval. Older messages remain visible in the conversation but are not copied into the inference window. The current request and current Workspace state always take precedence. Previous Assistant answers help resolve conversational intent only: they are not evidence, and their citations are reusable only when the same Source chunk is retrieved and allowed for the current response. Reset starts a new active conversation with empty inference history.

After each completed turn, the user message shows a muted, single-line Intent label of up to five words derived from the validated retrieval plan. It starts with the main operation, such as Retrieve all, Look up, Search, Summarize, Calculate, Compare, Update, or Assess, then narrows its scope. For a clear single operation stated explicitly in English or Slovak, that operation is normalized deterministically; compound or negated operation wording remains with the existing Assistant inference. This affects the feedback label only and does not replace retrieval routing. The label can retain an exact human identifier when useful, but does not repeat the prompt, expose a Source title, or claim retrieval succeeded. To correct it, 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. It copies the original prompt from a user message and the response from an Assistant message. Hover over a completed message bubble to reveal its compact creation date and time in the browser's local timezone.

When an Assistant answer refers to a Finding, the conversation shows a short excerpt from the Finding statement instead of its internal database identifier. Hovering the excerpt shows the complete Finding statement. Internal identifiers remain available only to the structured lineage operations that need them.

Assistant proposals are saved immediately as Proposed Findings. They are never accepted automatically. Ordinary Findings require evidence. Gaps, open questions, and missing-information proposals may explicitly record that evidence is unavailable.

When a generated structure exists, the assistant also receives its current version, Business and Technology Context drafts, complete Epic/Requirement hierarchy, Finding lineage, citations, review states, and validation result. It can explain the structure, identify missing coverage or duplication, and make typed changes. Supported changes can add a missing Business or Technology Context, edit Context summaries, edit Epics or Requirements, move Requirements, add artifacts, merge duplicate Requirements, or split a Requirement. An explicit grounded request to change an identifiable Context, Epic, or Requirement updates the generated draft directly instead of returning only a descriptive answer or requiring a separate proposal approval. All valid changes from one Assistant response are validated and applied atomically with evidence lineage and optimistic version checks. The response displays Draft updated with an Open Structure action. The Assistant does not accept, reject, restore, or promote Structure items; the end user explicitly reviews and accepts affected drafts in Structure.

Artifact generation also checks completeness across reviewed inputs: every eligible reviewed requirement Finding must contribute lineage to at least one generated Requirement. A response that omits a reviewed spreadsheet-row requirement Finding is rejected and corrected before a draft is stored.

Draft specification artifacts

The Draft specification artifacts step generates a structured, versioned candidate set after every Finding has been reviewed and every decision has been resolved. Generate structured draft launches a background job named Project structure generation, whose status changes from queued to running when its worker starts. Select that job title in Background jobs to return directly to the owning AI Workspace's Structure view. The set starts with exactly one Business Context and one Technology Context draft. Each is a concise, factual summary of no more than three sentences, grounded only in the reviewed Findings. The Business Context primarily answers what purpose the project serves from the consumer point of view; supported goals, actors, value, workflows, scope, and constraints clarify that purpose instead of replacing it with a feature list or technology description. When no technology decision or constraint is established, the Technology Context states that directly instead of inventing one. Epic candidates contain a key, name, objective, and scope. Requirement candidates contain a key, canonical English statement, and parent Epic. For a workspace associated with a Project, generation reads the localization selected in Project settings, requires every Context, Epic, and Requirement text in that locale, and displays that localized text in Structure while retaining canonical English internally. Promoted Requirements preserve both versions. Generated Requirement statements also use that Project's tenant format preset. A temporary workspace without a Project uses English and the tenant's default format preset. Reviewed Findings whose citations are unavailable, for example after their Source was deleted, remain available for audit but are ineligible for artifact generation and are omitted from the generated structure. At least one reviewed Finding with an available citation is required. Every generated candidate retains its own cited Source chunks and Finding lineage.

The Structure view presents the two Context drafts as full-width horizontal item rows, followed by one hierarchy in which each Epic is followed by its indented Requirements. Legacy drafts that predate Context generation show explicit Missing Business and Technology Context cards instead of an empty area. Its tab badge shows the number of proposed Contexts, Epics, and Requirements still awaiting acceptance. Every Context, Epic, and Requirement uses the same internal card layout as items in Decide: a full-width title and status row, content and evidence metadata below it, then a separated right-aligned action toolbar. Requirements remain visually nested through the indented, left-bordered list below their Epic. Managers can accept, edit, reject, or restore Contexts and other candidates, move Requirements directly, or use Ask AI on a Context, Epic, or Requirement. A missing Context card asks the Assistant to add the missing grounded Context directly to the structure. Validation blocks promotion until both Context types are present, keys are unique, required fields are present, every active Requirement belongs to an active Epic, and every Context, Epic, and Requirement is accepted and evidenced. The view reports evidence coverage for the active artifact set.

For a temporary workspace, Continue in Genesis creates or reopens an idempotent Genesis session with the reviewed structure and lineage. After Genesis creates the Project and its initial Specification, the associated workspace can promote the accepted candidates into that Specification. For an existing Project workspace, the compact promotion card keeps the current layout when an existing Specification is selected. Choosing Create new Specification expands the card into separate full-width rows for the target selector, the new Specification key and name, and the promotion action; the action becomes available after both new values are entered.

Direct promotion runs as an idempotent background job shown as Promoting artifacts. Its status refreshes from queued through running to completion while the Background jobs pane is open. It writes the accepted Business and Technology Contexts at Project scope and creates draft Epics and Requirements through FastAPI, records candidate-to-artifact mappings, and reports completed and failed items. Retrying a partial failure skips already-created artifacts and retries only missing or failed items. A Genesis handoff carries the same accepted Context drafts into the new Project as Project-scoped contexts and creates its initial Specification.

Review and decisions

Managers use the Decide view to accept, edit and accept, reject, or restore Findings. Its tab badge shows the number of Findings still requiring review or a decision. Finding cards use the full card width for the statement, keep type and evidence metadata together, and place actions in a compact toolbar below the content. Only proposed Findings and Findings needing a decision remain visible in the main review list. Accepted, edited, and rejected Findings are kept in the closed Reviewed Findings disclosure. Edit and accept opens the standard Finding modal; Escape cancels, Enter outside the multiline statement submits, and Enter inside the statement inserts a new line. Edited acceptance preserves the original proposal. Rejected Findings remain auditable. Open questions are Findings: they can be marked Needs decision, and Record decision opens the standard modal pane with a required decision note. In that pane, Escape cancels, Enter outside the multiline note submits, and Enter inside the note inserts a new line. Recording a decision preserves both the question and the decision note. Open questions are not duplicated as specification artifacts. Repeated assistant proposals with the same normalized Finding statement are not added again.

Auto approve asks for confirmation, then runs a background AIKOZO review over the exact current set of open Findings. AIKOZO uses the supplied evidence first and recognized best practices or recommendations for genuine gaps, then accepts, clarifies and accepts, rejects, or records a decision for every Finding. An open question or any Finding marked Needs decision can only receive a recorded decision or be rejected; the structured AI response schema prevents acceptance actions for those Findings. The complete structured decision set is validated before changes are applied. If the open Finding set changes while the job runs, the job stops instead of overwriting newer work. Each automated result keeps its AI action, rationale, and any decision note visible in the reviewed Finding for audit.

Deleting a Source removes its chunks and retrieval vectors, but historical Finding evidence remains as an unavailable snapshot instead of becoming a dangling link.

Linear workflow and Genesis

The assistant workbench keeps one continuous interaction across discovery, decisions, structure generation, structure changes, validation, and promotion. The progress path is Add Sources, Discover, Decide, Structure, and Promote. The slim Recommended next action strip identifies the current action and repeats its step number. The highlighted step and an aligned amber focus in the strip background provide the visual relationship without an arrow, connecting line, or shadow. Choosing Promote activates the Structure view and scrolls directly to Continue in Genesis for a temporary workspace, or to Promote accepted artifacts for an existing Project. Project candidates and standalone Project Drafts are not separate workspace steps.

When all Sources have been removed, Start here returns to the initial Add Sources state and resets its Findings, review, and draft counters. Retained Findings and drafts remain available as audit history in their workspace views, but they do not make the source-free workspace appear to have active discovery progress.

This Start here pattern is shared by the Specification, Implementation, and Feature workspaces. Each workspace keeps its own stages, KPIs, and actions while the placement and visual cues remain familiar. The content area associated with the recommended stage is also marked by a thin amber line on its left edge.

In a temporary AI Workspace, Continue in Genesis opens Project Genesis with the reviewed Epic/Requirement structure and lineage. A workspace for an existing Project promotes the same reviewed structure into an existing or newly defined Specification.

Non-goals

Project Workspace does not provide OCR, recursive or cross-origin crawling, object storage, external connectors, MCP resources, internet research by the assistant, ontology or terminology governance, inferred persisted facts, or implementation and delivery artifacts. It does not replace manual Project creation or the generic contextual assistant.