Structural positioning

@@ -27,13 +27,13 @@ references:
    url: "https://www.coso.org/guidance-on-ic"
---

Structural positioning is the approach PointSav uses to describe the architecture to the market: articulating commitments that are visible at the file system, the protocol, or the kernel level, rather than making named-competitor comparisons or relative performance claims. The architecture is built for institutional fiduciaries — public-company General Counsel, regulated asset managers, medical and legal practitioners — who evaluate software on architectural defensibility under audit rather than on marketing copy. The eight commitments described in this article are checkable by an auditor directly in the deployed substrate. By the end of this article, a reader will understand the eight structural commitments, the legacy patterns they structurally replace, and the customer segments they address.
Structural positioning is the approach PointSav uses to describe the architecture to the market: articulating commitments that are visible at the file system, the protocol, or the kernel level, rather than making named-competitor comparisons or relative performance claims. The architecture is built for institutional fiduciaries — public-company General Counsel, regulated asset managers, medical and legal practitioners — who evaluate software on architectural defensibility under audit rather than on marketing copy. Five of the eight commitments described in this article are checkable by an auditor directly in the deployed substrate today; three are planned architectural commitments, marked as such below. By the end of this article, a reader will understand the eight structural commitments, the legacy patterns they structurally replace, and the customer segments they address.

## Why PointSav positions structurally rather than comparatively

The customer base the platform serves does not buy software based on vendor comparisons. Asset managers, regulated professionals, and fiduciary institutions buy based on defensibility: can the system answer an auditor's questions directly from its own structure, without a vendor attestation letter?

Structural positioning addresses this directly. Every commitment in the table below is either present in the deployed substrate or it is not — no marketing claim intervenes. An independent auditor can verify the append-only property of the ledger, the absence of the delete verb from the code path, or the unidirectional constraint on the [[diode-standard|Diode adapter]], without relying on a vendor's self-reported controls summary. [^2] (Correction, 2026-08-02 — compliance-relevant, escalated: this "deployed, not marketing" framing is contradicted by this wiki's own more authoritative sibling article, `governance/compliance-and-continuous-disclosure.md`, which explicitly marks 3 of this table's 8 rows as "Planned"/"intended," not deployed: asset resolution on vendor failure (DARP), machine-readable compliance (OSCAL/SBOM/HBOM), and continuous audit (`service-audit`, which that same sibling article calls "an intended immutable log... intended to run below the OS" — `service-audit` doesn't exist as a crate at all). The append-only ledger row does check out as genuinely current. Flagged, not resolved — needs re-hedging the 3 planned rows to match the sibling article's own correct language.)
Structural positioning addresses this directly. Where a commitment is already present in the deployed architecture — the append-only ledger, the absence of the delete verb from the code path, the unidirectional constraint on the [[diode-standard|Diode adapter]] — an independent auditor can verify it directly, without relying on a vendor's self-reported controls summary. [^2] Three of the eight commitments below are planned rather than deployed today; each row states which.

Named-competitor comparisons are specifically avoided. The customer segments the platform targets make institutional purchasing decisions that outlast any two-vendor comparison table; the commitments described here hold regardless of what the competitive landscape looks like when the decision is reviewed.

@@ -47,10 +47,10 @@ Eight properties distinguish the PointSav substrate from the patterns it is desi
| Append-only ledger | The delete verb is absent from the [[worm-ledger-design|WORM ledger]] code path |
| Unidirectional command flow | The [[diode-standard|Diode adapter]] is the only routing component between authority and subject |
| Pairing as permission | No username-and-password databases exist anywhere in the substrate; access is governed by [[machine-based-auth|machine-based pairing]] |
| Continuous audit | The audit log runs at the system tier; an administrator cannot disable it |
| Asset resolution on vendor failure | The Digital Asset Resolution Package severs data cleanly and returns it to the owner on vendor failure |
| Continuous audit (planned) | The audit log is intended to run at the system tier, where an administrator cannot disable it |
| Asset resolution on vendor failure (planned) | The Digital Asset Resolution Package is intended to sever data cleanly and return it to the owner on vendor failure |
| Sovereign substrate | Compute and storage decouple across substrates — on-premises, leased, cloud — without an egress trap |
| Machine-readable compliance | OSCAL[^1] manifests, software bill of materials, and hardware bill of materials are exposed continuously rather than only during annual audit cycles |
| Machine-readable compliance (planned) | OSCAL[^1] manifests, software bill of materials, and hardware bill of materials are intended to be exposed continuously rather than only during annual audit cycles |

Each row is a structural argument. The replacement pattern — [[totebox-os|Totebox]] archives, [[machine-based-auth|machine-based pairing]], append-only ledgers, brokerless protocol mesh, semantic routing behind a verification gate — is the direct answer to the failure mode described in the row.