The first filename implementation immediately exposed a deeper problem. It used an internal SKU such as SKU-001, while the identifier people actually saw and used on the label was Batch No: 30267-0914. The download worked, but the data semantics did not. The system had selected an identifier that existed technically and was wrong operationally.

Production route

/tools/label/

Business identifier for filenames

Visible Batch No, when present

Example

30267-0914-BQ.png · 30267-0914-BQ.pdf

Physical size

No scaling; 80×80mm remains 80×80mm

Pagination verification

Six sizes produced one page each in Chromium

A filename is part of the data model

The answer was not to invent another piece of download-only naming logic that merely looked right. The filename and the visible Batch No now resolve from the same canonical data source. If the label shows 30267-0914, the PNG is suggested as 30267-0914-BQ.png and the PDF as 30267-0914-BQ.pdf. If those values diverge, at least one of them is no longer describing the batch in front of the user.

The same principle applies to PDF, although the browser interface is different. On macOS, when a browser print flow continues to Print → Save as PDF, the suggested PDF name comes from the print document title. The print path therefore replaces document.title briefly with the Batch-derived name before printing, then reliably restores the normal page title when printing ends, is cancelled or the window regains control. This is not a change to the page's SEO title. It is scoped state with an explicit entry and exit around one print session.

Exactly one page became one page plus a blank one

Once the naming path was coherent, the more interesting failure appeared: an 80×80mm label produced two pages in print preview, with the second page blank.

It feels obvious that an 80×80mm sheet should fit on an 80×80mm page. Browser layout, however, does not compare two integer millimetre values directly. CSS millimetres are converted to CSS pixels, and the print pipeline maps those pixels again into device and pagination units. At the page boundary, subpixel rounding, a default line box or a tiny contribution from the document body can place an edge that is numerically “exact” into the next pagination fragment.

The original print sheet was set to the full page dimensions, but it still participated in normal document pagination. Hiding only #root was weaker than it appeared, because it assumed that no other body child could contribute to print layout. That assumption is too broad when the output contract depends on an exact page boundary.

Fix the pagination, not the label dimensions

The correct fix was to isolate the print sheet from normal pagination flow. The print stylesheet strictly removes every non-print body child, zeroes margins, padding and line-box contributions on html and body, and positions the one print sheet absolutely at the page origin. It still retains the exact dynamic rule derived from the current label:

@page { size: <width-mm> <height-mm>; margin: 0; }

There is deliberately no 99% scale, no subtraction of 1mm from either edge and no A4 “fit to page” workaround. Those techniques might remove the blank page, but they would also change the output contract that matters most. An 80×80mm label must remain physically 80×80mm.

The editor and export preview can be enlarged to 150% to make the work surface easier to use, but that is presentation only. Canonical geometry and output pixels stay fixed: 100×100mm still exports as 1000×1000px, and 70×20mm still exports as 700×200px. Looking larger on screen is not the same as printing larger on paper.

Proving it was a pagination fix, not a lucky exception

Verification could not stop at 80×80mm. A special case for one size can create a convincing but fragile “fix.” Chromium pagination checks covered 70×20, 70×40, 80×60, 80×80 and 100×100mm, plus a custom 93×57mm label. All six produced exactly one page.

The automated environment could not directly read the page counter in the native macOS print-preview UI. The evidence boundary matters: the automation proved single-page Chromium print documents across that six-size matrix; it did not pretend to inspect a native UI value that was unavailable to it.

The last step happened outside the browser. After the print hotfix was validated in Production, the production-validated branch was reconciled back to GitHub main, leaving the source tree and the Production tree identical. That closure prevents a solved production bug from returning the next time an incomplete source branch is deployed.

“It downloads” is not done, and “it prints” is not done either. It is done when the data source, filename, physical dimensions, pagination behaviour and production source all agree.

This is a change in architecture and product strategy. It is not the abandonment of WEOUR OS.

Decision date

2026-10-03

What stops

Rebuilding order, inventory, purchasing, warehouse and finance functions that mature ERP systems already provide

Systems of record

ERP and marketplace systems, where they already own the data

What WEOUR OS becomes

Multi-platform operating data · trustworthy analytics · decision intelligence · control tower · AI agents

What this note is

A strategy decision, not a release announcement

Where we started

WEOUR OS began with a broad ambition. We wanted one system that understood stores, listings, products, warehouses and stock positions the way our business actually works across several marketplaces. Earlier notes in this log describe that work: stores that share a catalogue without sharing inventory, real warehouse locations, an inventory ledger, and the rule that an unknown stock value must never quietly become zero.

That work was not wasted. It taught us where the hard problems are. It also showed us, more clearly than any planning document could, how much of a full Commerce OS is not hard in a new way.

What changed

Once we were building it rather than describing it, a pattern became obvious. Orders, inventory movements, purchasing, warehousing and finance are large, careful and well-understood domains. Mature ERP systems, Lingxing among them, already cover a large share of the established core capabilities in these domains, along with a great deal of edge-case handling learned from real businesses.

Every week spent re-implementing those functions was a week spent catching up with software that already existed. At best we would arrive at a second copy of something we could already use. At worst we would create a second source of truth for the same order or the same stock position, which is exactly the kind of ambiguity WEOUR OS exists to remove.

So we stopped. WEOUR OS will not rebuild commodity ERP functionality unless there is a documented reason the existing system cannot meet a specific need.

Why this is the right trade

Engineering time is the scarcest thing we have. The useful question is not what we could build, but where building creates something nobody else gives us.

An ERP is very good at recording what happened inside its own scope. A marketplace is very good at reporting what happened on its own platform. Neither is designed to answer the questions that run a multi-platform business day to day: which numbers can be trusted right now, where the platforms disagree, which exception deserves attention first, and what we should do about it.

Those questions sit between systems. That is where WEOUR OS can be genuinely different.

What WEOUR OS is becoming

The shape of the system changes from one more all-in-one commerce system to a layer on top of the systems we already rely on:

ERP + marketplaces  →  WEOUR OS intelligence and control layer  →  human and agent decisions

In practice, this defines five directions for what we build next. They are directions, not five capabilities that are already finished:

• Multi-platform operating data. Data from the ERP and from each marketplace is brought into one normalised operating view, while keeping the original record and where it came from.
• Trustworthy analytics. Every figure carries its freshness and completeness. Partial data is shown as partial, and unknown is never presented as zero.
• Decision intelligence. Profitability, exceptions and forecasts are framed as decisions to make, not as more reports to read.
• Control tower. One place to see the state of the business across platforms, and what needs attention first.
• AI agents. Agents work on verified data and act within explicit permission and audit boundaries. High-risk operations and key business decisions remain subject to human authorization.

ERP and marketplace systems remain systems of record where that is appropriate. For now, our connection to the ERP starts as read-only: WEOUR OS reads, explains and cross-checks the data, and does not write back into the system that owns the record. This is where the integration begins, not a sign that it is complete.

What this does not mean

It does not mean WEOUR OS is starting over. The work on identities, inventory semantics, provenance and release safety carries forward. It is the foundation that makes cross-platform data trustworthy in the first place.

It also does not mean the new layer is finished. Much of the decision intelligence, control tower and agent capability described here is direction, not a production-ready feature. When those pieces ship, they will be recorded in this log with the same evidence standard as everything else.

The value of WEOUR OS is not owning the most features. It is turning data from different systems into decisions that can be trusted, explained and acted on.

WEOUR OS does not need to replace the ERP. It needs to become the trustworthy intelligence layer between the ERP, the platforms and the people who run the business.

Before this, multi-platform integration and catalog evidence, Yandex data ingestion, and unified business analytics definitions were advanced separately. The goal of this event was to connect them onto the same chain: to have Ozon and Yandex share the same order facts, rather than each maintaining its own definitions.

Another motivation was to make the boundary clear. The scheduler-related code has entered the deployed artifact, but "code deployed" and "running in production as planned" are two different things. This record deliberately leaves the latter blank, to avoid writing a not-yet-enabled capability as a completed running state.

What changed

The changes centered on channel integration, business analytics, and the Yandex platform adaptation: the console's channel and insights pages, the analytics library, the channel library, the Yandex platform adaptation layer, and the server-side logic.

On the data side, a foreign key constraint was added to the catalog, to protect observation evidence while not locking down the task rows themselves — this constraint has a corresponding test assertion. On the channel side, a round of RC fixes was made, covering store onboarding-related acceptance, time zones, shared secrets, and the PII allowlist.

On the documentation side, two deployments were recorded: one is the code deployment and P5 production observation of Yandex scheduler V1, and the other is the Yandex analytics main-chain integration. Both deployments are recorded in the overview document.

For specific versions, commits, deployed artifacts and digests, test counts, runtime state, and corpus counts, see the facts above.

Version

20260926-yandex-sched-add2ba4 / 20260926-yaxan-1771e0c

Main release commit

025b05e54469a5e8ab636915322cbe478f73131e

Production provenance commit

025b05e54469a5e8ab636915322cbe478f73131e

Deployed artifact and digest

20260926-yandex-sched-add2ba4 (recorded in docs/00-overview/CURRENT_STATE.md); 20260926-yaxan-1771e0c (recorded in docs/00-overview/CURRENT_STATE.md)

Test counts

see the catalog foreign key assertion in commit df4bb40802d4f0ee6af67d3bf7e09d74d39e7b5e

Runtime state

scheduler code deployed, not enabled

Current authoring corpus

8 notes / 24 variants (of which 1 is still unpublished)

How we verified it

Verification had three layers. The first layer is the commit itself: the main release commit and the production provenance commit point to the same SHA, showing that the record and the deployed artifact match up.

The second layer is tests: the catalog foreign key change carries an assertion, verifying that it protects observation evidence while not trapping the task rows.

The third layer is documentation: the two deployments each have a release id and a recorded date, and land in the overview document; the architecture document separately describes the design of Yandex order scheduler V1.

What it does not mean

It does not mean the scheduler is already running in production as planned. Code entering the deployed artifact, and the scheduler being enabled, scheduled, and observed to run stably, are conclusions at different levels.

It also does not mean multi-platform integration has been wrapped up. This event connected the order facts of Ozon and Yandex to the same definitions, but the scope of integration, subsequent platforms, and coverage of operational processes are not within this evidence.

It likewise does not mean the corpus is complete. As of the current repository there are still unpublished notes; the corpus count is the repository state captured at the time of writing, and later repository growth will not change the meaning of this number.

Scope of this round

Production infrastructure (record of this round of work): backup · scheduling · release · rollback

Backup cadence

Every 6 hours (launchd timer)

Backup success contract

Four gates: stream / decrypt / structure / durable

Backup health tiers

HEALTHY ≤ 7 hours · DEGRADED ≤ 12 hours · STALE > 12 hours (FAILED means a single attempt failed, not a tier)

Scheduler stagger budget

Default 30 seconds (floor 0 / ceiling 60), decoupled from the tick interval

Scheduler tick P50 (4 stores)

119.5 s → 31.9 s

Scheduler tick P95 (4 stores)

369.9 s → 55.3 s

Scheduler duty cycle

83.7% → 17.1%

Scheduler acceptance sample

11 ticks (4 stores)

First canonical deployment Trial

Failed on 2026-09-23, rollback executed by the pipeline

Production validation for this round

release 20260923-rpg13-7f685ca (CANONICAL, validation / smoke PASS)

Release governance test cases

123 → 157

Retention state at this round's observation point

release 19 · deletion candidates 1 · unknown provenance 6 · protected 5 (retention dry-run)

Scheduler correction commit

Anxin360/weour-os@e92b059

readiness / iowait correction commit

Anxin360/weour-os@d4cbe01

Foundation V1.1 trial branch tip

Anxin360/weour-os@b8cc817

Governance V1.3 commit

Anxin360/weour-os@7f685ca

Why we paused new features first

WEOUR OS is already running real data in production: real stores, a real scheduling loop, real release records. The more features there are, the higher the cost of a mistake; but before this, several things had never really been closed out:

• Immutable releases only accumulate, and the disk does not clean itself;
• Backups existed, but "did this backup actually succeed" was never automatically checked, and there was no health signal that could be consumed automatically;
• The scheduler looked busy, but most of that busyness was not business work.

None of these are feature problems; they are problems with how the system runs. Fixing them first makes every feature added afterwards cheaper.

What changed

1. Release retention: immutable releases need governed cleanup

Releases are immutable whole builds: switching means pointing a symlink at the new release directory, and rollback means pointing it back at the old one. This design makes rollback cheap, at the cost of a disk that keeps growing — at audit time, release directories accounted for about 74% of the host's used disk (44.12 GB / 59.44 GB used), while the same disk also had to leave headroom for builds.

So cleanup was written as a classification priority, not "delete the oldest":

CURRENT > IMMEDIATE_ROLLBACK > DIAGNOSTIC > FAILED_TRIAL > VALIDATED_ANCHOR
      > MIGRATION_BOUNDARY > MANUAL_PROTECT > UNKNOWN_PROVENANCE > ROUTINE

Only ROUTINE enters routine quota cleanup; no other category is ever swept away in passing. One rule matters especially: the release of a failed Trial is not downgraded to ROUTINE just because its commit later landed on main. Classification rests only on lifecycle evidence, not on directory names, timestamps, or chat logs.

2. Backup: from "there is a backup" to "a backup that can be checked"

The shape of backup was not rebuilt from scratch: the backup host pulls, production only exposes a restricted forced-command stream, and the decryption private key never enters the production host. The changes happened on the pull side:

• Cadence and RPO: every 6 hours (launchd timer), with a target RPO of 6 hours. The cadence is explainable and does not depend on a drifting interval timer.
• Four gates: a run counts as successful only after all four gates — stream, decrypt, structure, durable — pass. A pg_dump exit code of 0 was never success by itself.
• Failure is failure: if any gate fails, the run is FAILED, last-success is not updated, and cleanup does not happen.
• Health tiers: HEALTHY (≤ 7 hours) / DEGRADED (≤ 12 hours) / STALE (> 12 hours) are derived from hours since last success and can be consumed directly by monitoring as an exit code; FAILED describes a single attempt, not a tier.
• Failure-injection tests: covering remote failure, undersized artifact, decryption failure, invalid structure, overlapping runs, stale lock, retention policy, and corrupted health state.

The last step was wiring the health signal back into production: after the four gates pass, the backup host pushes the snapshot to production through a restricted identity that can write only one fixed file — it cannot switch releases, cannot restart services, and cannot read any key.

3. Scheduler: separating the semantics of tick and stagger

Diagnosis first produced an uncomfortable conclusion: over the run window with 4 stores, 96.8% of tick wall-clock time was spent in deterministic stagger sleeps — 84 seconds of real work out of 2610 seconds. Counted per action, the sleeps alone came to 4150 seconds/hour, close to 115% of wall clock.

The root cause was mixed semantics: the stagger window was bound to the tick interval (180 seconds), and the fixed sleeps of multiple actions on the same serial runner were accumulated serially.

The correction separated the two: the tick interval is used only for reporting cadence and no longer participates in stagger computation; stagger has its own budget, default 30 seconds, selectable 0 / 30 / 60, with invalid values falling back to the default. Measured results after deployment:

• tick P50 119.5 s → 31.9 s, P95 369.9 s → 55.3 s;
• duty cycle 83.7% → 17.1%;
• planned sleep matches actual sleep, and the remaining time is explainable API and DB work;
• timer, cadence, store switches, and concurrency budget were not changed.

4. One canonical release pipeline

Release is no longer a string of manual commands but an ordered, reproducible pipeline:

provenance → preflight → release lock → scheduler quiet window → source
  → build backend → monitored build → immutable release + manifest
  → candidate validation → rollback readiness → atomic switch → restart
  → readiness → functional smoke → state write → history → retention dry-run

Several parts are deliberate: builds happen only inside the scheduler's quiet window; the switch is atomic; the rollback target is verified once before and once after the switch; and the exit code of systemctl restart is explicitly recorded as "unit started", not "application ready".

5. The first Trial failed, and was preserved in full

The first canonical deployment Trial ran through its own success path, then failed at the smoke stage, and the pipeline executed its own canonical rollback.

The cause was not a problem with the application: systemctl restart returning only means the unit started, not that the port is bound. The smoke at the time was an immediate HTTP check with no readiness wait, so it observed connection refused and gateway errors.

The handling is the point: nobody bypassed the pipeline to fix this step by hand. The pipeline stopped according to its own failure contract and executed the rollback, that release was preserved for diagnosis, and the cleanup stage performed not a single deletion. Production kept serving normally on the pre-switch release.

The correction released afterwards turned readiness into bounded polling and made build monitoring actually measure iowait. On the re-run, the earlier failure mode was correctly absorbed by the new logic as transient unreadiness rather than a deployment failure.

6. Governance: leaving evidence for both "who may release" and "what was released"

The rules added this round are for our future selves:

• canonical deploy only: day-to-day releases go only through the pipeline; exceptions must be explicitly marked.
• deploymentMethod: every new lifecycle record carries a method enum, history is appended rather than rewritten, and records that cannot be determined are marked UNKNOWN_LEGACY, never guessed as CANONICAL.
• Failed Trial classification: FAILED_TRIAL is determined by lifecycle evidence and does not consume routine cleanup quota.
• Diagnostic evidence first: before deletion, a KB-level diagnostic record containing no keys must be written back and verified; if it cannot be written, deletion is refused.

At this round's observation point (production release 20260923-rpg13-7f685ca), the retention policy was presented as a dry-run: the record showed 19 releases, of which 1 deletion candidate, 6 unknown provenance, and 5 protected. Cleanup happens only when the evidence is complete (the target is confirmed unreferenced, and the diagnostic record has been written back and verified).

How we verified it

At every step, verification was anchored as far as possible in reviewable evidence rather than "it looks fine":

• Backup was verified by failure-injection tests and real four-gate runs, and the health signal is consumed by monitoring;
• The scheduler correction was first simulated in an isolated environment with measured offsets, then compared before and after deployment using 11 real ticks;
• The release pipeline was verified by letting it run one real release end to end: readiness passed, functional smoke passed on six routes, state was written by the pipeline, and only then was the retention dry-run performed;
• Governance rules are covered by test cases, from "a failed Trial is not downgraded" to "the releaser rejects anomalous payloads".

What it does not mean

It is not a feature release, and it does not mean the infrastructure is finished.

In this round's record, the limitations of backup are written down explicitly: there is only one decryption key and it sits on the same machine as the ciphertext; there is no second off-site copy; there is no PITR, so the RPO is the 6-hour cadence; media backups have no retention policy; and roles and global objects are not in the dump. These are known trade-offs, not overlooked details.

The scheduler correction only addresses where time is spent; it is not a concurrency or performance optimization.

Governance does not cover all history either: at this round's observation point there were still old releases whose provenance could not be determined, and they were conservatively retained.

This note belongs to the round of work from 2026-09-22 to 2026-09-23. The production states in it are facts at this round's observation point, not the state at any later moment; subsequent production changes are outside the scope of this note.

Finally, it is not a promise about future versions, timelines, or capabilities. What is recorded here is an infrastructure upgrade that already happened, and the evidence supporting it.

Where the evidence is

Every factual statement in this note points to an object that can be looked up: the correspondence between commits, deployment release identifiers, and test case counts is registered in the facts table above and in this note's evidence entries. The body of this note only explains meaning and does not repeat the identifiers.

Before this, publishing Build content relied on manual judgment: whether content was compliant, whether its structure was complete, and whether the runtime could read it correctly after publishing all lacked a unified checkpoint. Once the content format diverged from runtime expectations, problems often only surfaced after publishing.

The goal of this change was not to add features, but to turn "can this content be published" into a question that can be answered before publishing: content first passes contract validation, then CI gates, and only then enters the publishing flow.

What changed

The changes centered on several interlocking parts: workflows, the content directory, documentation, the runtime content module, scripts, and tests.

On the content side, schema and topics definitions were introduced, making the relationship between notes, variants, and topics explicit; the script side validates content against the contract; the test side covers both the PHP and Node check paths; the workflow side strings preview and gates together so that checks must pass before publishing.

The release itself concluded with a production deployment; the deployment record was written into the repository documentation and tagged with the corresponding validation tag. For the specific version, commit, artifact digest, test counts, and corpus counts, see the facts above.

How we verified it

Verification had two layers. The first layer is automated checks: the PHP and Node check suites run in CI, with several gates, and only when all pass is it allowed to continue. The second layer is production verification: after the artifact was deployed to production, the runtime reported its own state and the scale of content it loaded.

Two corpus figures from different points in time need to be distinguished:

• Production corpus at the time of the 1.3.5 deployment | 5 notes / 15 variants / 13 topics
• Current authoring corpus as of the current repository state | 6 notes / 18 variants (1 of which is still unpublished)

The former is the runtime snapshot at deployment time; the latter is the repository's current content state. It is normal for the two to differ: the repository can contain drafts that have not yet been published.

Version

1.3.5

Main release commit

57bf785a0bcd6e886397de776cbe7bd7156fd64c

Production provenance

4b4ec32a3aac70a8222ca7255f0db38fb6683200

Deployed artifact

weour-core-1.3.5.zip

Artifact SHA-256

f660c0d9b48cbe774a3ba10d380eedfbf9a4fee5cf1a49c97c024ee7c1ee28ab

Plugin manifest SHA-256

952f570124787702fc8c71ce6ebd5410dca3099730b212d805189f3764d2a703

Deployment environment

production

Deployment state

deployed

Runtime state

ready

Runtime version

1.3.5

Runtime module count

12

Test counts

PHP 1100 checks / Node 97 checks

Gate count

5

Production corpus at deploy time

5 notes / 15 variants / 13 topics

Current authoring corpus

6 notes / 18 variants (1 of which is still unpublished)

What it does not mean

It does not mean content publishing no longer needs manual judgment. The pipeline checks the contract and structure; it does not check whether the content itself is appropriate or worth publishing.

It does not mean everything in the repository is live. The repository's current content count is greater than the runtime count at deployment time; the difference comes from drafts that have not yet been published.

It also does not mean this flow already covers all future content forms. This validation targeted the current content contract and runtime read path; forms outside the contract are not within the scope of this validation.

Finally, it is not a commitment to future versions, timelines, or capabilities. What is recorded here is a release and validation that already happened, and the evidence supporting it.

This note is the moment that changed. Ledger #1 is the first entry in WEOUR OS where a real physical count became recorded inventory, in a form that can be audited later.

What existed before the ledger

Two real warehouses were already modelled, and their active storage locations had been replaced with verified physical ones — the 1,306 locations described in the previous note. Marketplaces and channels were reporting what they could see. None of that is the same as WEOUR knowing.

Observed inventory is evidence. It is what a source told us, at a time, from its own point of view. A central ledger is different: it is where WEOUR decides what it holds, and it only earns that status by being traceable back to a physical fact.

What a first physical count actually changes

A count is not a sync. It is a person standing in front of a location and confirming what is there. When that result is written into the ledger, three things become possible for the first time:

• a number exists because someone counted it, with a scope, a time and a location behind it;
• the difference between what the system previously showed and what was physically found becomes a recordable movement rather than a mystery;
• later observations can be compared against a decision instead of against each other.

Real warehouses in scope

2

Active storage locations

1,306

First entry

Opening balance from a physical count

Ledger movement

OPENING_BALANCE +55

Automatic inventory writes

None

Approval requirement

Explicit, per movement class

OPENING_BALANCE +55 is a bookkeeping movement, not a demand signal. It records that the counted reality and the ledger now agree on a first number in that scope. It is published here because it is exactly the kind of movement a central inventory system has to be able to explain months later — and because inventing a cleaner-looking number would have defeated the point.

The rules that made it possible

The count could only be entered because four rules already existed in the system:

1. NOT_INITIALIZED ≠ 0. A scope that has never been counted is not empty; it is unknown, and it stays unknown until someone counts it.
2. NOT_REPORTED ≠ ZERO. A channel that failed to report has not told us anything, and a failed report never becomes a shortage.
3. Observed Inventory ≠ Central Inventory. Channels keep reporting what they see. The ledger records what WEOUR has decided, after reconciliation.
4. Candidate ≠ Approved. A proposed movement is a proposal. It becomes inventory only through an explicit approval step, and never by automation filling in a gap.

What this does not mean

It does not mean inventory is now "solved". Two counted warehouses are two counted warehouses. The ledger is only as good as the next count, and the next scope is the one that has not been initialised yet.

It also does not mean the numbers are final. A physical count is a statement about a moment. The system has to keep the moment attached, so that a later difference is a difference between two known states rather than an argument about who is right.

Why this is the first ledger note

We are publishing the ledger series because it is the least glamorous and most load-bearing part of a commerce operating system. If the system cannot say what it knows, what it observed and what it decided — separately — then every other number above it is decoration.

Ledger #1 is the first entry where those three things stopped being the same thing.

NOT_INITIALIZED

The system has never been told what is here

NOT_REPORTED

A source that normally reports has not reported

ZERO

We know, from a specific source at a specific time, that the amount is none

Observed inventory

What a channel or warehouse reported, kept as evidence

Central inventory

What WEOUR has decided the truth is, after reconciliation

These are five different things. Systems that collapse them into one column are not simpler — they are just unable to tell you why a number is what it is.

Why "unknown" must not become "zero"

Zero is a claim. It says a countable quantity is none. When the system has no information, writing zero makes an unknown fact look like a known one, and every downstream decision inherits the lie:

• A storefront marks an item unavailable because a report failed, not because the item is gone.
• A replenishment rule fires on a phantom shortage.
• A reconciliation report shows a difference that is really a missing source, and the team spends a day chasing nothing.

None of this looks like a bug. It looks like normal data.

How we represent it

An unset inventory state is stored as an explicit state, not as a number. States are part of the model:

• NOT_INITIALIZED — the record exists, and no source has ever provided a value.
• NOT_REPORTED — a source is expected to report and has not yet, or has failed.
• A numeric value — an actual claim, always attached to its source and its observed time.

The display layer is allowed to be friendly. The storage layer is not allowed to guess.

Observed inventory is not central inventory

The second half of the principle is that observations never become the ledger by accident.

Every marketplace and every warehouse reports something, and those reports answer different questions at different moments. Observed inventory is what we were told. Central inventory is what WEOUR has decided, after reconciling the observations, the physical counts, and the known gaps.

Keeping that boundary explicit is what makes multi-store selling honest: five stores can each report what they see without any of them silently rewriting what WEOUR owns.

What it costs, and why we pay it

This principle is inconvenient. It means more states, more explicit handling, and fewer places where a default value can quietly fill a hole. It means dashboards have to say "unknown" instead of showing a reassuring zero.

We pay that cost because the alternative is an operating system that is confidently wrong. A commerce OS earns trust by knowing what it does not know — and by saying so in the database, not only in the interface.

NOT_INITIALIZED ≠ 0. NOT_REPORTED ≠ ZERO. Observed inventory is not central inventory.

The locations were placeholders.

The problem with numbers that are merely consistent

Placeholder locations are easy to generate and easy to trust. They fit the schema, they pass validation, and they produce charts. The failure only appears when someone has to physically pick something up, or when two different people describe the same shelf in two different ways and the system insists they are different places.

That is the trap: placeholder data does not look like missing data. It looks like data.

Replacing the placeholder set with the real one

We rebuilt the warehouse master from how the facilities actually operate, then loaded it as the authoritative set of storage locations.

Verified storage locations

1,306

Facilities modelled

Suzhou, Shenzhen

Approach

Physical location first, system record second

Placeholder locations

Retired, not repaired

Unknown mapping

Kept unknown until a real location is confirmed

The count is not the point. The point is that every one of those 1,306 locations corresponds to a place a person can walk to, and that the two facilities are modelled on the same rules rather than two local conventions.

What the change surfaced

Replacing placeholders with reality exposes everything that had been quietly leaning on the fake data:

• Items that had a placeholder location and no real home needed a decision, not a default.
• Legacy codes that meant different things at each facility had to be resolved instead of merged.
• Any process that assumed every item is always somewhere had to tolerate "we have not confirmed this yet" as a legitimate state.

That last point is the one that changed the system most, and it is the subject of the next note in this log.

Why we publish this

A warehouse master is the least glamorous part of a commerce operation and one of the few parts that everything else depends on. Publishing it as a build note is a way of stating the standard we now hold ourselves to: storage locations are physical facts, and a system that invents them is worse than a system that admits it does not know.

A location record that nobody can walk to is not inventory data. It is decoration.

With two stores, it is possible to hold the whole picture in one person's head. Which listing belongs to which store, which price belongs to which channel, and what happens when both stores try to sell the last unit are all answerable by memory. That stops working at three, and it fails loudly at five.

Store isolation is a boundary, not a copy

The first instinct when adding a store is to duplicate. Copy the catalogue, copy the stock numbers, copy the mapping table, change the store identifier. It looks fast, and it creates a second version of the truth that will disagree with the first one within a week.

We took the opposite position:

Principle

What it means in practice

Store is an identity, not a stock bucket

A store owns listings, prices, and channel rules — not its own inventory ledger

Listing is a channel artefact

Two stores may list the same physical product under different listing identities

Product identity is shared

The thing being sold is described once and referenced everywhere

Stock is observed, never copied

A store reports what it sees; the system records the observation instead of inventing a balance

Adding a store now adds a channel identity. It does not add inventory.

Why "observed inventory" instead of a per-store balance

Marketplaces tell you things at their own speed and in their own vocabulary. One channel reports sellable quantity after its own reservations. Another reports what it was told last night. Neither number is wrong, and neither number is the whole truth about the physical goods.

So we stopped asking each channel to be the source of a balance. A channel reports an observation: this is what I can see, from this source, at this time. Observations are recorded, compared, and reconciled — they are not silently merged into a single number that nobody can audit.

That one modelling decision is what makes five stores tractable instead of five times the maintenance.

What we had to build to make it hold

Running five storefronts under one operating model required three things that were not obvious at two:

• A single product identity that listings point at, so the same physical item is not re-described per channel.
• A mapping layer between marketplace listing identities and our own SKUs, because a seller article and an internal identifier are not the same thing.
• A resolver that answers "which channels can sell this, and at what price" without letting any single channel overwrite the shared record.

None of this is exotic. All of it has to be enforced, because the failure mode is silent: a duplicated stock number still looks like a valid number.

The cost of multi-store is not the fifth store. It is the second copy of the truth that you did not notice you created.

What changes as stores are added

With isolation held at the channel boundary, adding a store becomes an operational task instead of a data-migration project. The next store can go live with its own listing set, its own pricing rules, and its own reporting — while the products and the physical stock they reference stay where they were.

That is the property we were actually buying when we built the model. Not more stores. Fewer surprises per store.

We tried to look at it that way. We compared platforms that could hold more SKUs, more stores, and more integrations. Every one of them answered a version of the question. None of them answered ours.

The problem was never the software category

An ERP is built around a company that already knows what it owns. It assumes a clean master record, one place where the truth lives, and processes that mostly run inside one organisation. That model works well when your business is one catalogue sold through one or two channels.

Our reality is different. The same physical product lives in several marketplaces under different listing identities, arrives from different supply routes, and reports stock at different times in different formats. A purchase order, a marketplace listing, and a warehouse location are three different objects with three different lifecycles. Software that flattens them into one row is not wrong — it is just answering a simpler question than the one we have.

What we are building instead

WEOUR OS is a commerce operating system: a set of systems that describe how goods, listings, warehouses, and decisions relate to each other, and that keep those relationships honest while the business runs.

Layer

Responsibility

Channel

Each store keeps its own identity, pricing rules, and listing lifecycle

Inventory

Observations are recorded with source and time, not silently merged

Warehouse

Physical locations are modelled as first-class records

Mapping

SKU, listing, and product identities are linked, never assumed identical

Agents

Automation proposes and executes against explicit system rules

Each layer can be replaced. The relationships cannot.

Built in production, not in a slide deck

The reason this is published as a build log rather than an announcement is that we are not starting from a whiteboard. We are changing systems that already carry real stores, real warehouses, and real listings. Every design decision has to survive contact with a live operation on the same day it is made.

That constraint is uncomfortable and useful. It rules out elegant architectures that cannot be deployed incrementally, and it forces us to write down the rules that the business already follows implicitly but has never had to state.

What this means for the storefront you are looking at

weour.com is not being replaced by a new website. It is one of the systems. The marketplace storefront, the Russian and Chinese market channels, the supplier workflows, and the internal operating layer are being brought under the same model of what a store, a product, and a stock position actually are.

An operating system for global commerce is not a bigger database. It is a smaller number of rules that everything else can be trusted to follow.

What comes next

The next notes in this log go into the parts that were hardest to get right: how stores stay isolated while sharing one catalogue, why adding a store must not duplicate inventory, what happened when placeholder warehouse locations met real ones, and why an unknown stock value is never allowed to quietly become zero.

That is the build. We will keep publishing it as it happens.