Co.PropertyTeam wikiCo.Property20 October 2026
Press slash to search. Arrow keys select a result.
Internal knowledge
Browse the wiki

Reference

Glossary

Checked

Shared terms make handovers safer. The most important distinctions are record versus task versus knowledge, source versus projection, and assigned versus evidenced versus accepted.

Download page Markdown
Interactive mapSelect a node to read its explanation. Use Work on this beside the section to prepare a change.
Glossary: use words that preserve the decision boundary diagramA source record leads to a task. The task produces evidence. A verifier accepts or rejects the outcome. Knowledge explains how the cycle should work next time.Record — Glossary: use words that preserve the decision boundaryRecordTask — Glossary: use words that preserve the decision boundaryTaskEvidence — Glossary: use words that preserve the decision boundaryEvidenceAccepted result — Glossary: use words that preserve the decision boundaryAccepted resultKnowledge — Glossary: use words that preserve the decision boundaryKnowledge
The terms connect facts, actions, evidence, and accepted outcomes.Solid · information flow
Read the diagram as text

A source record leads to a task. The task produces evidence. A verifier accepts or rejects the outcome. Knowledge explains how the cycle should work next time.

  • Record → Glossary: use words that preserve the decision boundary
  • Task → Glossary: use words that preserve the decision boundary
  • Evidence → Glossary: use words that preserve the decision boundary
  • Accepted result → Glossary: use words that preserve the decision boundary
  • Knowledge → Glossary: use words that preserve the decision boundary
What it does

Give nontechnical readers a compact vocabulary that keeps status labels honest and makes an operational question easier to investigate.

Responsibility

Writers use plain terms that another person can verify.

Next step

Use “record” for a fact-bearing item, “task” for accountable work, and “knowledge” for reusable explanation.

Core terms: record, task, knowledge, source, and projection

Checked

A record describes something, such as a property, reservation, owner relationship, subscription, or decision.

Read the details

A record describes something, such as a property, reservation, owner relationship, subscription, or decision. A task is an accountable next action with a responsible person, due time, and verifiable outcome. Knowledge is a reusable explanation, such as an SOP, incident lesson, report interpretation, or decision note.

A source is the authority for a specific observation or transaction. A projection is a distributed or displayed view of information from another writer. Naming both prevents a dashboard card or cache from becoming an accidental source of truth.

A worktree is a separate working copy for one change, so edits do not disturb the installed application. A regression test checks that existing behavior still works after a change. A fixture is a controlled example, such as a duplicated message or failed provider response, used to check that behavior safely.

A pull request (PR) asks someone to review a proposed code change before it joins the shared version. A release is the separate step of putting reviewed changes into the running system. Passing tests and merging a PR do not by themselves prove a release is installed or working for staff.

Current
Checked — the terms come from the documented company model and infrastructure boundary.
Proposed next state
Use the terms consistently in navigation, UI labels, prompts, and PR descriptions.
Expected outcome
Readers can tell whether they need to inspect a fact, perform work, follow a procedure, or investigate a display.
Checks to include when changing this section
  • Check local search returns each term using text-only results.
  • Check generated Markdown includes the same term definitions as the page.

State labels: assigned, in progress, evidenced, accepted, and exception

Checked

Assigned means a person has an expected next action.

Read the details

Assigned means a person has an expected next action. In progress means work is underway. Evidence received means a result has been supplied and can be checked. Accepted means an authorised verifier recorded a supported outcome. An exception means a known gap, mismatch, or stale source still needs ownership.

These labels should not be collapsed. A completed cleaning task can remain unverified; a recently opened dashboard can remain stale; a connected adapter can remain unaccepted. Precise labels help the next person make the right decision.

Current
Checked — labels preserve the documented turnover and freshness decision boundaries.
Proposed next state
Use fixtures to keep UI labels accurate when a workflow changes.
Expected outcome
Status language becomes a reliable pointer to evidence, not a substitute for it.
Checks to include when changing this section
  • Test states where work is complete but evidence is missing, and where source is stale but screen is recent.
  • Check no state label silently becomes accepted without verifier input.

Say what is known, pending, and proposed

In progress

Use Checked for a specific documented or verified item and In progress for unfinished evidence, acceptance, or recovery work.

Read the details

Use Checked for a specific documented or verified item and In progress for unfinished evidence, acceptance, or recovery work. The current wiki deliberately keeps turnover evidence, LINE acceptance, provider freshness, and cold boot recovery visible as pending.

Avoid words such as “live”, “complete”, or “confirmed” unless the relevant source and reviewer support them. A concise, honest status helps more than a broad reassuring statement.

Current
In progress — the listed operational areas need current real-world evidence before any broader completion language is justified.
Proposed next state
Update only the specific status that new evidence supports, with source and reviewer in the authorised record.
Expected outcome
Readers do not mistake documentation coverage for operational completion.
Checks to include when changing this section
  • Check all pages render only Checked or In progress human-status badges.
  • Check pending topics remain pending in llms.txt and per-page context exports.

Apply with care

A concrete safe example

Example, responsibilities & checklist

Choose the precise state

Say “assigned, evidence pending” when someone has been asked to clean but no result has been verified. Do not say “ready” unless the confirmed property, required evidence, and authorised acceptance are all present.

Responsibilities

  • Writers use plain terms that another person can verify.
  • Reviewers challenge labels that combine separate states into a reassuring shortcut.
  • Operators connect a term to a source record, task, or accepted decision.
  • Contributors preserve these distinctions in UI labels and test fixtures.

Checklist

  1. Use “record” for a fact-bearing item, “task” for accountable work, and “knowledge” for reusable explanation.
  2. Use “projection” for a distributed view and name its source/writer separately.
  3. Use “fresh” only for a complete source read plus successful publication.
  4. Use “accepted” only after an authorised verifier has recorded the outcome.
Expected outcome

A reader can choose a precise label for what is known, what must happen next, and what still needs acceptance.

Traceability without sensitive material

Source pointers and exports

This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.

Documentation references
  • Handoff / pages/organisation.html
  • Handoff / pages/workflows.html
  • Handoff / pages/infrastructure.html
Page MarkdownPage context JSON