For the complete documentation index, see llms.txt. This page is also available as Markdown.
Project settings and lifecycle
Rename, inspect, retire, or delete a project with explicit impact controls.
Project settings control the identity and terminal lifecycle of an operating boundary. Before changing a production project, inventory the attached dataset versions, Live ontology, workflow, open tasks, assignments, Issues, releases, API jobs, and downstream consumers that refer to it.
Read the current project settings
Project Settings page with project name and dangerous zone
Project Settings shows the current project identity and keeps irreversible deletion in a separate Dangerous zone.
Open the project and choose Settings. The page shows the current project name and, for applicable text work, source-text editing controls. The Dangerous zone is intentionally separated because deleting a project is irreversible.
Rename the project
Edit project name dialog
Edit opens a focused name dialog. Confirm changes the display name; it does not replace the project's stable identity or reconfigure its data contract.
In Project name, choose Edit.
Enter the durable operating name used by your team.
Choose Confirm.
Reopen the project list, queue links, and any human runbook that uses the display name.
A rename changes the human-facing label, not the meaning of the attached data, ontology, workflow, releases, or stable project ID. Automation should use the project ID rather than the display name.
Change source text where supported
Text projects can expose source-text editing from Project Settings. Treat a source edit as a data change: identify affected spans, entities, relations, review decisions, and release output; make the smallest correction; then reopen representative work and revalidate downstream offsets and content.
Retire a project without losing operational history
Use an explicit retirement runbook before considering deletion:
stop new assignment and automated intake;
resolve, reassign, or close open annotation and review work;
close or transfer Issues and ownership;
publish or cancel pending releases according to policy;
record the final dataset, ontology, workflow, and release versions;
disable project-specific service jobs and confirm no scheduled client still targets the project;
retain the project when audit, provenance, or historical access is required.
Delete a project
Delete Project in the Dangerous zone permanently removes the project boundary. Use it only when the owner has approved deletion, dependencies are reconciled, and required output or audit evidence has been retained elsewhere. The product confirmation is the last guardrail; it is not a substitute for the lifecycle review.
Deletion cannot be undone. Do not delete a project merely to hide completed work or clean up navigation; retain or archive operational history according to your governance policy.
Change-impact record
For every material setting or lifecycle change, record the project ID, owner, reason, previous and new state, attached resource versions, in-flight work treatment, test evidence, downstream validation, and approver.
