Task context - ArchDocs

Find recorded decisions, documentation and open work for a task, with scope and authority labels kept separate.

Run task context before changing a service or resuming a design doc. You get recorded links and labelled sources for the work you describe. Task context and code locations are generally available on Team and above. The query uses no language model and consumes no AI credits.

Describe the task and scope

Open Context in the sidebar and enter your task. You can also start from the context card on a design doc or object page, follow labelled Ask AI sources, or call get_task_context over MCP. Ask AI has its own AI credit usage; the context query itself has none.

Only task is required. Add what you know:

Input	What you supply
`task`	The work you are about to do, up to 500 characters.
`repo`	`fullName` as `owner/repository` and `paths` as file paths. Supply an empty paths list for repository-only context.
`designDocId`	The starting design doc.
`objectIds`	Catalog objects the task affects. A catalog is optional.
`spaceId`	A filter on the results. Sharing a space is not evidence of relevance.
`page`	A group, offset and limit when you need more results.

Read the groups

The response keeps these groups separate. Each group contains items, total and nextOffset; follow the offset to read more instead of assuming the first page is complete.

For acceptance criteria: Early access. Email hello@archdocs.io to turn it on for your organization.

Group	Response field	What you find
Current	`current`	Scoped records whose recorded authorization or documentation freshness supports a Current label.
Uncertain	`uncertain`	Records with missing freshness, unapproved intent, amendments or other stated uncertainty.
Related	`related`	Records connected through adjacent or broad relationships.
Open questions	`openQuestions`	Unresolved questions from the selected context.
In progress	`inProgress`	Planned work not yet recorded as done. Missing recorded changes never imply missing implementation.
Acceptance criteria	`criteria`	Conditions and their implementation-specific verification labels.
History	`history`	Superseded, abandoned or other historical records.
Found by text search	`foundByText`	Text matches whose names alone do not establish scope.
Constraints and decisions	`structuredItems`	Structured items captured from source passages, when present.
Deferrals	`deferrals`	Postponed approaches and their reopening conditions, when present.

Each item has a summary, reason and path, and may include a label; MCP also returns a URL. Open the full record when you need its reasoning. A deferral means postponed, not ruled out. Its reopening condition prompts reconsideration and does not authorize the approach.

Use the label legend

Label	Meaning
Current	A scoped relationship plus recorded authorization or known documentation freshness, with no recorded supersession or applicable disqualifier. Current never means the record governs the task.
Related	An adjacent or broad relationship. Read the reason before applying it to your change.
Uncertain	The recorded facts leave applicability uncertain. The reason names the gap.
Historical	The record is superseded, abandoned, deprecated, rejected or otherwise historical.
Approved by a person	Human authorization is recorded and in force for that source.
Documented, not approved	The source documents architecture. It has no design approval.
Written by an agent	Agent-authored intent without human authorization. It is not verification or approval.
Via a dependency	The source is one dependency step away from the selected scope.
Same repository	The relationship is broad and has no matching path evidence.
Lineage	A supersession relationship connects the source to the starting design doc.
Confirmed current by a person	A person confirmed documentation freshness. This is not acceptance-criterion verification.

Authorization, freshness, verification, author and relationship strength remain separate facts. Unknown freshness is never fresh. A Satisfied criterion's Verified label applies to that criterion under its policy; it does not approve nearby text or make the record a standing constraint.

Check the relationship strength

Strength	Recorded relationship
Scoped	An explicit object link, an owned or showing canvas document, a matching code location, or the exact synced diagram YAML path being edited.
Adjacent	A direct dependency or supersession lineage of the starting design doc.
Broad	The same repository through a PR or docs-as-code sync, or a repository code location when you supplied no paths.
Text	A search match without a recorded scope relationship.

Repository-only relationships stay broad even in a monorepo. A nonmatching code location does not bring a record into scope for the supplied paths.

Add code locations

Open Code locations on an object, canvas document or design doc page. Add a repository and path pattern, for example example/payments and services/billing/**. This example maps a record to files; it does not read those files. Writes require objects:manage for objects or docs:write for documents, as well as access to the record.

Run context with the paths you edit. Unmatched paths appear in scope.unresolvedPaths. The response's scope.used records the repository, path and object counts, design doc ID and space ID supplied in the request. coverage.partial and coverage.notes identify gaps such as missing scope, few recorded links, unresolved records or unavailable verification.

The server requires docs:read, filters records by your current access and checks access when you open a full record. Records you cannot open are not shown. Context comes from recorded links and text, not from reading code. It does not establish that your documentation covers every part of the task.