---
name: Arco Daily Scan
version: 1.0.1
status: active
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---

# Arco Daily Scan

## Purpose

Daily Scan is Arco's recurring review Function.

It reviews configured recent working sources, interprets what has changed since the previous successful scan, and routes relevant findings to the Arco components enabled in the deployment.

Its purpose is to stop useful information remaining trapped in calls, messages, email and rough notes without requiring each Arco component to scan those sources independently.

Daily Scan orchestrates the review. It does not own the domains it updates.

## Core principle

Read recent source material once where practical, understand it as a whole, then route relevant findings to the appropriate enabled owners.

Do not run separate full source scans for Notes, Decisions, Context, Tasks, Development or other consumers when the same source period can be interpreted once.

Efficiency must not come at the cost of materially relevant information.

## Core and local runtime

Core defines the reusable Daily Scan behaviour.

```text
Arco Core
arco-daily-scan.md
        ↓ deployed as
readme-daily-scan.md
        ↓
user-local/private Notes area
readme-daily-scan-local.md
daily-scan/
```

Where Daily Scan is personal to an individual inside an organisation, its local configuration and operating state belong in that user's local/private Arco Notes area rather than the shared organisational runtime.

The local Notes area should contain:

```text
readme-notes.md
readme-notes-local.md
readme-daily-scan.md
readme-daily-scan-local.md
daily-scan/
    daily-scan-register.csv
    logs/
```

The `daily-scan/` folder owns the chronological run Register and complete run logs. It exists to keep operational evidence tidy and traceable without creating a separate information domain.

## System Setup relationship

`readme-system-setup.md` is the deployment manifest and is the authoritative source for which Arco components are enabled.

Daily Scan must use System Setup to determine eligible participating components.

Do not duplicate module or Function enablement state in `readme-daily-scan-local.md`.

If System Setup records that a component is disabled or not deployed, Daily Scan must not load that component's scan behaviour.

If System Setup changes, Daily Scan should reflect the current enabled deployment state on the next run.

Each participating component owns the meaning of information relevant to its domain. Daily Scan orchestrates those rules rather than reproducing them centrally.

## Sources

Call transcripts are the primary source category for Daily Scan.

A deployment may configure additional sources, but Daily Scan must not assume that common platforms or source types are available.

When proposing source options during setup, use the deployment state and provider/runtime information already recorded in System Setup. For example:

- offer Teams only where the deployment/runtime indicates Microsoft 365/Teams is available;
- offer Slack only where Slack is part of the configured environment;
- offer email only where an email source is available to the runtime.

Do not ask the user about systems that System Setup does not indicate are available.

### Custom sources

Daily Scan must support deployment- or user-specific sources that are not part of the conventional Arco model.

A custom source may be a folder, inbox, document collection, database, transcript library, application or other bounded source that the runtime can access.

Custom sources belong in `readme-daily-scan-local.md`, including the source's exact reference and any local preparation route it requires.

Core must not promote a custom source into a universal source type merely because one deployment uses it.

Custom source configuration should be descriptive enough for Daily Scan to understand:

- what the source is;
- where it is;
- how new/unprocessed material is identified;
- whether preparation is required before interpretation;
- what successful processing means for checkpointing.

## Setup and invocation

Daily Scan has two operating modes:

- setup;
- execution.

`setup daily scan` establishes local parameters and operating state for a specific deployment/user.

`run daily scan` executes the configured scan.

A deployment may configure manual invocation or scheduled invocation. Scheduling is an invocation mechanism, not a separate Daily Scan process.

Core intentionally does not prescribe one universal `setup daily scan` storage schema. The deployment/user runtime may define the smallest local configuration needed for its sources, checkpoints and scheduling, provided it preserves this operating contract and keeps provider-specific detail local. Repeatedly proven reusable fields may be promoted into Core later without reopening the existence or boundary of Daily Scan.

## Scan period and checkpoint

Daily Scan works from the previous successful source checkpoint to the current run.

On the first run, where no checkpoint exists, ask the user when they want scanning to begin.

Do not silently scan an unlimited historical period.

Different sources may require different checkpoint mechanisms, such as:

- timestamp;
- transcript/file processing state;
- message ID;
- email received timestamp;
- document processing marker;
- custom source state.

Only advance a checkpoint after the relevant source period has been processed successfully.

## Source preparation

Daily Scan may invoke a separate source-preparation capability before interpreting source content.

For transcripts, source preparation may include conversion, cleaning, speaker normalisation or other processing needed to create a usable transcript representation.

Provider-, client- or deployment-specific source-preparation rules do not belong in this Core Daily Scan file.

Daily Scan should consume the prepared representation and preserve source provenance.

## Scan workflow

A normal run should:

1. load `readme-daily-scan.md`;
2. load `readme-daily-scan-local.md`;
3. read System Setup to determine currently enabled Arco components and relevant runtime/provider state;
4. resolve configured standard and custom sources;
5. load only the scan requirements of enabled participating components;
6. determine each configured source period since its previous successful checkpoint;
7. invoke required source preparation;
8. read each prepared source period once where practical;
9. interpret the material broadly rather than keyword-searching for expected outputs;
10. identify relevant units and relationships;
11. cross-reference existing owner state where materially necessary;
12. propose or execute changes according to the destination owner's rules;
13. record ambiguity, review requirements and failures;
14. update checkpoints only for successfully processed source periods;
15. append the run to `daily-scan-register.csv` and write the complete run log.

## Routing

Daily Scan may identify that one source passage is relevant to more than one owner.

That does not mean identical durable content should be duplicated across owners.

Route the relevant representation to each owner while preserving that owner's source-of-truth boundary.

Where one interpretation feeds several consumers, prefer a shared bounded processing representation over rereading the original source for each owner.

Any shared representation is an intermediate processing artifact, not another durable business source of truth.

## Notes integration

Where Notes is enabled in System Setup, Daily Scan may identify:

- a new Note;
- an update to an existing Note;
- a Note that should be parked, dropped or superseded;
- material that appears ready for promotion;
- rough Notes intake that has now been reconciled into durable Notes state.

Notes remains private personal working memory.

Daily Scan does not make private Notes public. Promotion/handoff follows the destination owner's rules.

## Monthly Notes intake

Where Notes uses a monthly native-word-processor intake, Daily Scan should ensure the current month's intake exists.

At the beginning of a run:

1. resolve the current month;
2. check the configured Notes intake location;
3. use the existing current-month intake when present;
4. if absent, create it using the deployment's native word processor;
5. update local configuration to point to the new current intake.

The local configuration owns the exact folder, naming convention and provider reference.

A deployment may use a visible processed marker, such as a tick beside a fully processed date. Do not mark a date processed until all material under that date has been handled successfully.

## Staleness and backlog

Arco may surface a Daily Scan staleness warning when another local process encounters evidence that the scan has fallen materially behind.

For example, while logging Notes the system may notice an unusual backlog relative to the most recent successful Daily Scan.

The observing process should not take over Daily Scan or independently process the backlog. It should surface the stale state and suggest running Daily Scan.

Do not hard-code a universal one-day warning threshold in Core. The useful signal is material divergence between expected cadence/state and actual backlog.

## Proposal and execution

Daily Scan does not create a universal approval model.

Each destination owner determines:

- whether an identified change may be written directly;
- whether it remains a proposal;
- whether approval, verification or acknowledgement is required;
- who has authority to act.

Daily Scan must respect those owner and Governance rules.

## Run Register and logs

Each user-local Daily Scan runtime should maintain one chronological `daily-scan-register.csv`.

The Register is the lightweight index of runs.

Each run should also have a complete Markdown log under `daily-scan/logs/`.

A scan is an execution record, not a lifecycle object, so Daily Scan does not require unresolved/resolved Registers.

A run should record enough evidence to establish:

- run identifier;
- start and completion time;
- invocation mode;
- source periods covered;
- source checkpoints before and after;
- enabled participating components resolved from System Setup;
- custom sources used;
- what was created, updated, proposed or handed off;
- what required review;
- what failed;
- whether the run completed, completed partially or failed;
- source references sufficient to trace a later change back to the material that caused it.

The Register and logs are operational provenance, not another source of business truth.

## Failure behaviour

A partial run must not create a false impression that all source material has been processed.

If processing fails:

- preserve the previous successful checkpoint for the affected source;
- record what succeeded and failed;
- avoid duplicate durable writes on the next run;
- surface material ambiguity where human input is required.

Independent sources may still complete where that is safe.

## Boundaries

Daily Scan does not:

- own Notes, Decisions, Context, Tasks or Development;
- maintain its own duplicate list of enabled Arco components;
- assume Teams, Slack, email or any other platform exists without deployment evidence;
- make a user-specific source into a Core convention;
- define provider-specific transcript-cleaning rules;
- duplicate module operating rules;
- search all historical information on every run;
- promote private information merely because it was detected;
- advance checkpoints after incomplete processing.

## Confirmed decisions

- Daily Scan is a Core Function.
- System Setup is authoritative for enabled component participation.
- Local Daily Scan state lives in the user's private/local Notes area.
- Daily Scan maintains one chronological Register plus complete run logs under a `daily-scan/` folder.
- Custom user/deployment sources are supported without becoming Core conventions.
- Standard source prompts are constrained by what System Setup says is available.
- Setup and run are distinct behaviours.
- Daily Scan may be manual or scheduled.
- The exact `setup daily scan` local schema will be proven in a deployment before being standardised in Core.

## Deployment-led evolution

The following implementation details may continue to evolve through deployment evidence without reopening Daily Scan's Core boundary:

- participating-component scan interfaces;
- local `setup daily scan` configuration fields;
- Register columns and run-log presentation;
- combining multiple component scan requirements efficiently;
- scheduling handoff conventions across runtimes such as ChatGPT and Claude.

Promote only repeatedly useful, provider-agnostic behaviour back into Core.


## Canonical references

[arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view).

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 1.0.1 | Restored canonical provider-link references. | Stoirm Arnold — Defrag invocation | Codex Work |
| 25-Sep-2026 | 1.0.0 | Promoted Daily Scan to an active Core Function: the reusable scan, checkpoint, routing and evidence contract is established, while exact local setup storage remains deliberately deployment-defined. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 24-Sep-2026 | 0.2.0 | Made System Setup authoritative for enabled participants; constrained standard source prompts to configured deployment capabilities; added user-defined custom sources; established the user-local `daily-scan/` Register/log structure, setup/run distinction and staleness signalling; deferred the exact setup schema until deployment proof. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 24-Sep-2026 | 0.1.0 | Created first Daily Scan Core candidate: deployment-aware participant discovery, transcript-first and optional source scanning, whole-period interpretation rather than keyword searches, source checkpoints, source preparation boundary, owner-led routing, monthly Notes intake rollover and run evidence. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |