Skip to content

FEATURE SPEC

Questions or comments?

Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.

Project Creation & Task Force Assembly

Novaworks AI | Super Agent orchestration (nova-superagent-agent) + x_novaw_platform

Parent Feature Set: ../concept.md.

Major Change History

Version Date Author / Notes
1 2026-08-10 Eswar Vandanapu — Initial draft, derived from row 1 of the parent concept.md's Feature index.

Problem Statement

A Project Owner who wants to run an ad hoc initiative has no structured way to declare it, name its goal, or pull together the right people — it's all manual coordination across email, Slack, and spreadsheets before any planning even starts. There's also no governance over who's allowed to start one in the first place: today, nothing stops (or permits) anyone from declaring an initiative a "project," because the concept doesn't exist on the platform yet.

Use Cases

Use Case 1: An HR Ops practitioner (Project Owner) wants to launch a company-wide upskilling program. Today, they'd start by emailing a handful of colleagues asking if they can help, with no shared record of who's actually on board, which matters because two weeks routinely pass before the group even agrees who's involved, let alone what they're doing.

Use Case 2: A System Admin wants project creation restricted to Directors and above, matching how the company already governs other cross-functional initiatives. Today, there's no policy layer to configure that at all — every future Project Owner would need to be manually told (or trusted) to only start projects they're authorized for, which matters because an ungoverned initiation path undermines any attempt to keep ad hoc work accountable.

Use Case 3: A Manager is asked to join a task force as a subject-matter contributor for an upskilling initiative that isn't theirs to own. Today, there's no platform record of that membership at all — they'd just start getting emails — which matters because they have no single place to see what they've been pulled into or who else is involved.

Scope

  • A Project Owner — anyone the customer's configured initiation policy allows — creates a Project by naming it and describing its goal, either by telling HR Concierge in chat ("I want to start an upskilling project for the Sales org") or through a structured form; either path produces the same Project record.
  • The Project Owner assembles the Project's Task Force by looking up and adding any employee — Manager, HR Operations, or Employee acting as a subject-matter contributor — no role restriction on task-force membership itself.
  • Before a Project record is created, the system checks the caller against the customer-configured initiation policy (HR only, HR plus Managers at or above a set level, or anyone) and blocks creation if they're not eligible.
  • A System Admin configures that initiation policy through the same feature-flag targeting console already built for guardrail policy configuration (../../ai-guardrails-sensitive-routing/policy-configuration-console/spec.md) — this Feature extends that existing mechanism rather than building a second one.
  • Each added Task Force member is notified they've been added and to which Project.

This Feature does not itself produce AI-generated content — parsing a typed-or-spoken goal description into a Project's name/summary fields is structuring input, not generating output the user needs to review. The generative and agent-driven pieces (charter drafting, task generation, plan review) belong to Features 2–5.

Out of Scope

Value

Without this Feature, nothing else in this Feature Set has anywhere to attach — there's no Project record for a charter to belong to, no Task Force for tasks to distribute to, and no governance over who's allowed to start one. It's the one Feature every other Feature in this set depends on existing first.

Delivery

UX Description

A "Start a Project" entry point reachable either from a chat request to HR Concierge or a short structured form in the Nova Super Agent surface, where a Project Owner names the initiative, describes its goal in a sentence or two, and adds Task Force members by searching the company directory.

Key User Flows

  1. Project Owner tells HR Concierge "I want to start a project for [goal]" → Super Agent checks the initiation policy → if eligible, asks for a project name (if not already stated) and prompts to add Task Force members → creates the Project record and confirms it's ready to move into planning.
  2. Project Owner not eligible per the configured policy → Super Agent declines to create the Project and states who is eligible (e.g. "Only HR Operations and Directors+ can start a project today — ask one of them to sponsor this") rather than silently failing.
  3. Project Owner uses the structured form instead of chat → same name/goal/Task-Force-member fields, same eligibility check, same resulting Project record.
  4. System Admin opens the existing guardrail-policy-console pattern, now also listing a "Project Initiation" policy, and sets it to HR only / HR plus Managers at a chosen level / anyone → change takes effect without a deploy.
  5. A person is added to a Task Force → receives a notification naming the Project and who added them, with a link to the Project once it exists.

Human Override & Fallback Strategy

  • Every creation attempt is gated by the System-Admin-configured initiation policy; there's no autonomous override — a blocked Project Owner must be added to an eligible role/level or get an eligible person to create it on their behalf.
  • If a goal description given in chat is too thin to name the project meaningfully (e.g. just "start a project"), HR Concierge asks a clarifying follow-up rather than creating an incomplete or empty record.
  • System Admin retains full override of the initiation policy at any time, including narrowing or widening it for a pilot group — same override model as the guardrail policy console.

AI Feedback Loop

Not applicable — this Feature does not include AI-generated output. Structuring a stated goal into a Project name/summary is input parsing, not generated content requiring review; the agent-generated content this Feature Set produces belongs to Features 2 through 5.

Acceptance Criteria

  • A Project Owner who is eligible per the configured initiation policy can create a Project by naming it and describing its goal, via either a chat request to HR Concierge or the structured form, and both paths produce the same Project record.
  • A Project Owner who is not eligible per the configured initiation policy is blocked from creating a Project and is told who is eligible instead of receiving a silent failure.
  • An eligible Project Owner can add any employee — Manager, HR Operations, or Employee — to a Project's Task Force by looking them up in the company directory.
  • A person added to a Task Force receives a notification naming the Project and linking to it.
  • A System Admin can set the project-initiation policy (HR only, HR plus Managers at or above a configurable level, or anyone) through the same console used for guardrail policy configuration, and the change takes effect without a deploy.
  • A Project record and its Task Force can exist with no charter, tasks, or planning content attached yet — Feature 2 is not a prerequisite for Feature 1 to complete.
  • collaborative-charter-goal-planning (Feature 2): begins only once this Feature's Project record and Task Force exist; this Feature doesn't touch charter or goal content itself.
  • ai-guardrails-sensitive-routing / policy-configuration-console: this Feature's initiation-policy configuration extends that same feature-flag targeting mechanism rather than introducing a second one — confirm the targeting layer can express role/level-based rules (see Open Questions) before building on it.

Risks

Risk Severity Mitigation
A misconfigured initiation policy silently locks out legitimate Project Owners, or unintentionally opens creation to everyone Medium Surface the active policy plainly whenever someone attempts creation, and log every policy change the way the guardrail console logs its own for traceability.
The feature-flag targeting layer may only support flat group membership, not the "at or above a level" (e.g. Director+) rule this Feature needs Medium Confirm the targeting layer's data model can express level-based rules before Construction; if it can't, this Feature needs its own extension to that layer, not a workaround.

Open Questions

  • Can a Project Owner remove or replace a Task Force member after initial assembly, or is membership fixed once a Project is created?
  • Does the feature-flag targeting layer already support "at or above a level" (e.g. Director and above) rules, or only flat group/role membership? This affects whether Feature 1 can ship the level-based policy option as described or needs to start narrower.
  • Figma / Claude Design artifact for the "Start a Project" surface is not yet available.

For internal engineering review only.

Novaworks AI | Confidential