Skip to content

PointSav Documentation

The engineering library for the PointSav platform — operating systems and services for regulated businesses that own their data, their AI, and their record-keeping outright. Where the monorepo holds the code, this wiki holds the reasoning: architecture, services, security, and the governance commitments that bind future development.

PointSav Digital Systems

Anti-homogenization discipline

← All revisions

220eb162 · PointSav Digital Systems ·

editorial(governance): rehedge anti-homogenization-discipline's overclaimed operational status (Track-B) — confirmed fuse_adapters() is a symbolic-ID stub (real GGUF merge deferred pending llama.cpp LoRA hot-swap), matching substrate/adapter-composition.md's already-confirmed finding, not a live per-tenant/protocol adapter composition as claimed; confirmed zero senior-signed verdict tuples exist yet (apprenticeship-substrate.md's already-confirmed finding), rehedged the 'every editorial action produces a verdict-signed tuple' claim; fixed a fabricated 4-item editorial task-type taxonomy (register-tighten/frontmatter-normalize/citation-insert have zero hits anywhere in the codebase) to the real 5-value audit event_type enum (prose-edit/design-edit/graph-mutation/anchor-event/verdict-issued); same operational-status rehedge applied to the ES pair's composition claim

View the full record as of this revision →

@@ -34,22 +34,17 @@ The same dynamic operates across organisations. A platform-hosted writing assist

The platform's default editorial action is `flag`, not `rewrite`. When the assistant identifies a potential issue, it surfaces the issue and proposes an edit; it does not silently rewrite the user's text. The user's voice is the authority unless the user explicitly delegates a rewrite.

This default applies across every editorial task-type:

- `prose-edit` — flag banned vocabulary, register drift, citation gaps; do not rewrite.
- `register-tighten` — propose tightenings; mark them clearly as proposals; let the user accept individually.
- `frontmatter-normalize` — fill in missing fields; never silently overwrite a present-but-unconventional value.
- `citation-insert` — propose `[citation-id]` references; surface the candidate citation source for verification.
This default applies across every audit-logged editorial event type — `prose-edit`, `design-edit`, `graph-mutation`, `anchor-event`, and `verdict-issued`: the assistant flags banned vocabulary, register drift, or a proposed change and lets the contributor accept or reject it, rather than applying it silently.

A user who explicitly requests "rewrite this in institutional register" gets a rewrite. The flag-don't-rewrite default does not block delegation; it requires the delegation to be explicit.

## Per-tenant adapters preserve voice

The platform's adapter-composition algebra separates the per-tenant adapter from the protocol adapter. The per-tenant adapter trains on the customer's own corpus inside the customer's own [[totebox-os|substrate]]. It learns the customer's voice — the words they use, the sentence rhythms they favour, the register they default to.
The platform's adapter-composition design separates the per-tenant adapter from the protocol adapter. The per-tenant adapter trains on the customer's own corpus inside the customer's own [[totebox-os|substrate]]. It learns the customer's voice — the words they use, the sentence rhythms they favour, the register they default to.

When the protocol adapter (PROSE / COMMS / LEGAL / TRANSLATE) composes with the per-tenant adapter at request time, the output reflects both: the genre conventions of the protocol and the voice of the tenant. A README authored by the platform inside Customer A's substrate sounds like Customer A; the same README authored inside Customer B's substrate sounds like Customer B.
The intended mechanism: when the protocol adapter (PROSE / COMMS / LEGAL / TRANSLATE) composes with the per-tenant adapter at request time, the output reflects both — the genre conventions of the protocol and the voice of the tenant. Composition itself is not live yet; today it returns a symbolic composed identifier rather than merging adapter weights, pending a runtime capability the platform depends on but does not control the timeline of. A README authored inside Customer A's substrate is designed to sound like Customer A once composition ships; the same README inside Customer B's substrate, like Customer B.

This is the Writer Brand IQ pattern adapted to customer data ownership. Brand-voice adapters work; the platform establishes that they work without the customer's text leaving the customer's substrate.
This is the Writer Brand IQ pattern adapted to customer data ownership — brand-voice adapters that work without the customer's text leaving the customer's substrate, once composition is operational.

## Forward-looking — federated voice preservation

@@ -59,7 +54,7 @@ A customer who does not contribute continues to benefit from base-model improvem

## What anti-homogenization is not

It is not a refusal to suggest improvements. The discipline is the opposite of inertia — every editorial action produces a verdict-signed training tuple that improves the per-tenant adapter over time. The customer's voice is preserved, not frozen.
It is not a refusal to suggest improvements. The discipline is the opposite of inertia — every editorial action is designed to produce a verdict-signed training tuple that improves the per-tenant adapter over time. That pipeline captures real activity today; the verdict-signing step itself — a human confirming an edit before it trains the adapter — has not processed a real verdict yet. The customer's voice is preserved, not frozen, once the loop closes end to end.

It is not a rejection of standardisation. The platform's banned-vocabulary list, sentence-length budgets, and register parameters are standardised across all tenants because the absence of `leverage` and `seamless` is universally an improvement. Standardisation operates at the level of mechanical defects; voice operates at the level above that.
Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is currently a trade name of Woodfine Capital Projects Inc. ("Woodfine"), planned to become a wholly-owned Woodfine subsidiary upon incorporation. PointSav does not itself offer, sell, or solicit any security. Any securities offering associated with Woodfine's real-property direct-hold solutions is made exclusively by Woodfine, and only by means of the applicable Private Placement Memorandum.

No investment advice. This wiki's content is provided for engineering, operational, research, and development purposes. Nothing on this wiki constitutes investment advice or a solicitation to invest in any Woodfine partnership or direct-hold solution.

Intellectual property. The PointSav name, trade name, wordmark, and marks, together with all current and future PointSav- and Totebox-branded products, services, and offerings — and the software, source code, documentation, design system, and all related materials — are proprietary to Woodfine and its affiliates, except for components identified as open source. No rights are granted except as expressly set out in a written license or agreement. The full trademark notice appears in the footer of every page on this site.

Open source components. Portions of the platform are made available under permissive open-source licenses identified in the accompanying repository. Use of those components is governed by their respective license terms.

No warranty; informational use. Content on this wiki is provided for general informational purposes only and does not constitute a representation, warranty, or commitment with respect to product functionality, availability, pricing, or roadmap. Some articles describe planned or intended features, capabilities, and milestones — language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Confidentiality. Where an article describes an operational or deployment detail that is not intended for public disclosure, that article is not published on this wiki. Content here is general-purpose engineering documentation, not customer-specific configuration.

Jurisdiction. Woodfine Capital Projects Inc. is organized in British Columbia, Canada. References to the Sovereign Data Foundation on this wiki describe a planned or intended initiative only, not a current equity holder or active governance body.

Changes to this notice. PointSav may update this notice from time to time; the version posted on this page governs.

Not a filing system. This wiki is not a securities filing system, an electronic disclosure repository, or a substitute for SEDAR+ or any other regulatory filing system. Formal securities filings are made through the applicable regulatory filing system, not through this wiki.

Full disclaimer. This notice supplements, and does not replace, the full Disclaimers article. In the event of any conflict, the full Disclaimers article governs.

Read the full disclaimer →