Izveidot kontuCreate account
‹ All playbooks
Watch our own register entry for unexpected changes

company.registry-watch·version 1.0.0·draft2 to verify

Watch our own register entry for unexpected changes

The company's register entry (UR) matches reality every week, and any unexpected change is caught within seven days and routed to the right playbook.

JānisCompany Analystruns itProfile ›
Whenscheduled · weekly — weekly — every Monday the agent checks the company's own entry in the Register of Enterprises
Who actsthe agent prepares only
Time10 min active per week
CountryLatvia
Sign in to run thisThis playbook opens inside Brain Club. Sign in to read and run it.

When to use

Every week, for the company's own entry in the Latvian Register of Enterprises. This is a watch, not a filing: it detects drift, it does not fix it. Not for making a change — a board member change goes through company.change-board-member, a legal address through company.change-legal-address, a new SIA through company.register-sia-lv. Not for watching other companies (competitors, partners) — that is agents.research-company.

Before you start

  • The registration number and exact legal name are recorded in the company profile.
  • The expected state is written down somewhere checkable: board members with roles, legal address,
  • The agent can read the public UR entry. If the company has a paid UR subscription for official

What a run requires1

  • Approval · S5 · ownerthe run stops until a named person records the decision

Any step can wait until a date and reopens by itself; every closed step leaves evidence (a note, a link, a number).

The trail6 steps

  1. Read the current UR entryagent

    Open the company's public entry on ur.gov.lv: board members and their roles, legal address, share capital, status, registration date, latest filings.

    Done when the entry as shown today is captured (screenshot or copied fields with the date).

  2. Compare field by field with the expected stateagent

    Go through the list: each board member (name, role), the legal address, share capital, contact data, status.

    Done when every field is marked same / differs / not recorded.

  3. Check the deadlines the entry impliesagent

    Read the status and the latest annual report filing; note whether the current year's report deadline is approaching. ⚠ verify the exact annual report deadline for this company's financial year — it depends on the year-end and is shown in the company's UR entry; do not assume a fixed date.

    Done when the next deadline, if any, is written down with its source (the UR entry itself).

  4. Write the weekly check recordagent

    One short record: date, fields compared, result (clean / N discrepancies), link to the captured entry. If clean, this is the whole output.

    Done when the record exists and is findable by date.

  5. Decide on any discrepancy. — only if S2 found a differenceownerneeds approval · owner

    Approval · S5 · owner — the run stops until a named person records the decision

    Present the discrepancy with evidence: what UR shows, what the company believes, since when (if the previous check records allow an interval). The owner picks: it is an error to correct (route to the change playbook), it is a known change nobody recorded (update the expected state), or it needs an official extract / a lawyer before deciding.

    Done when the owner has named the route in writing.

  6. Route and recordagent

    For a correction: open the task with bc tasks add (or link the goal with bc goals add) naming the playbook that fixes it — company.change-board-member, company.change-legal-address, or, for a suspected unauthorised filing, escalate to the owner and management.decision-record first. For a known change: update the expected state so next week's S2 is clean.

    Done when the task or the updated expected state exists and links to this week's record.

Checks — how we know it worked

  • The check record for this week exists and names every field compared — "UR looks fine" is not a record.
  • Any discrepancy has: the UR value, the expected value, the date noticed, and an owner decision.
  • The expected state used in S2 is the one updated after the last accepted change, not a stale copy.
  • No discrepancy from a previous week is left without an owner decision or a linked task.

If it goes wrong

SymptomResponse
A board member appears who no decision appointedDo not assume a registry error. Escalate to the owner the same day; check for forged filings; ⚠ verify how to contest an unauthorised entry — start at ur.gov.lv and a Latvian commercial lawyer.
Legal address differs from realityTreat as urgent — official mail goes there. Route to company.change-legal-address; check whether any deadline mail was already sent to the wrong address.
Status shows reorganisation or insolvency we did not startSame-day escalation to the owner; this is outside this playbook — record it in management.decision-record and take legal advice.
UR site unavailable on the scheduled dayRun the check the next working day; note the delay in the record. Two consecutive misses → tell the owner the watch is not running.
Every week finds the same trivial differenceThe expected state is stale — fix it in S6, not the registry.

What each step leaves behind

  1. S1the entry as shown today is captured (screenshot or copied fields with the date).
  2. S2every field is marked same / differs / not recorded.
  3. S3the next deadline, if any, is written down with its source (the UR entry itself).
  4. S4the record exists and is findable by date.
  5. S5the owner has named the route in writing.
  6. S6the task or the updated expected state exists and links to this week's record.

Evidence to keep

Weekly check record with date and result · captured UR entry (screenshot or fields) for any week with a discrepancy · the owner's decision in S5 (who, when, what route) · links to tasks opened in S6 · any official extract requested, with its issue date.

How this playbook improves

After every 10 runs ask: were there any discrepancies, and how old were they when caught (the interval between the change and the first check that saw it)? How many false alarms — fields that differed only because the expected state was stale? Did any check get skipped, and why? A new version changes the field list or the comparison source that caused the miss, and says so in its change note.