Capability statement provenance
Only publishable evidence is quoted or linked here. RAS-01 records that restricted evidence was assessed; it is not a public citation for undisclosed details.
| ID | Statement | Semantic class | Public evidence | Restricted evidence disposition | Candidate |
|---|---|---|---|---|---|
| P01 | Retaining content is distinct from permitting later AI use. | rule/invariant | Storage pillar lines 21–30 ↗ | assessed; no private detail published | retain governed content |
| P02 | Processing preserves source identity and records a linked derivative. | rule/invariant | Storage pillar lines 53–57 ↗; current derived-representation contract | assessed; disagreement retained privately | derive content from a retained source |
| P03 | Context eligibility is explicit, inspectable, and removable; no allocation is assumed. | rule/invariant | Storage pillar lines 59–65 ↗ | assessed | allocate retained content to a context |
| P04 | Retrieval context is assembled separately from model generation. | capability purpose | Retrieval lines 15–21 ↗; PIOS retrieval model ↗ | assessed; realization is narrower than the full requirement | assemble governed retrieval context |
| P05 | Retrieval selection is bounded and explainable. | rule/invariant | Retrieval lines 47–68 ↗; PIOS context packets and logs ↗ | assessed | assemble governed retrieval context |
| P06 | A conversation consolidation is a derivative linked to source entries. | rule/invariant | Retrieval lines 79–90 ↗; cognitive-memory companion ↗ | declared structure assessed; reachability not publicly claimed | consolidate conversation history |
| P07 | A structured proposal carries rationale/evidence and receives a durable disposition. | rule/invariant | Proposals lines 28–49 ↗; PIOS governing principles ↗ | app realization not publicly claimed | decide a governed proposal |
| P08 | A standing rule requires confirmation, logs applications, and falls back when confidence is insufficient. | rule/invariant | Rules lines 51–72 ↗; PIOS governing principles ↗ | app realization not publicly claimed | establish and apply standing rules |
| P09 | Processing and decision messages are effects of another capability, not independent Capability MLEs. | reasonable inference | MLE analysis in boundary decisions | not applicable | Communication MLEs |
| K01 | The personal glossary preserves stable local meanings, aliases, status, and relationships without becoming a general dictionary. | rule/invariant | PIOS Personal Glossary ↗ | assessed | maintain a personal glossary term |
| K02 | Named meaning objects and organizing labels are distinct: one preserves personal referents and meaning; the other supports grouping and filtering. | rule/invariant | Glossary and Naming lines 27–66 ↗; PIOS glossary and taxonomy ↗ | assessed | maintain glossary term; manage organizing label |
| K03 | Machine-detected names remain candidates until governed confirmation; detection must not silently create accepted meaning. | rule/invariant | Automated Naming lines 15–34 ↗; PIOS glossary lifecycle ↗ | restricted implementation assessed; details withheld | detect candidate glossary term |
| K04 | AI-assisted labels are non-authoritative cues kept distinct from owner-confirmed labels. | rule/invariant | AI-Assisted Labels lines 15–45 ↗; PIOS soft semantics ↗ | assessed | manage/apply AI-assisted labels |
| K05 | AI-assisted label use is optional in filtering and retrieval, with exclusion as the safe default. | recommended default | AI-Assisted Labels lines 36–64 ↗; PIOS soft semantics ↗ | assessed | apply an AI-assisted label |
| K06 | Role and Mode context attached to objects does not grant access and retains lifecycle history. | rule/invariant | Context Tags lines 15–49 ↗; PIOS context-tag lifecycle ↗ | assessed | apply contextual classification |
| K07 | A deliberate knowledge note is a governed durable capture, distinct from raw conversation and from capabilities attached to it. | capability purpose | Notes Pillar lines 15–47 ↗; PIOS Knowledge Layer ↗ | assessed | maintain a deliberate knowledge note |
| K08 | Note revisions preserve prior state and silent content edits are prohibited. | rule/invariant | Notes Pillar lines 63–67 ↗; PIOS Knowledge Layer ↗ | assessed | maintain a deliberate knowledge note |
| K09 | Owner-authored self-description and evidence-backed profile assertions are distinct knowledge forms and must not convert automatically. | rule/invariant | Profile App lines 23–43 ↗; PIOS profiles ↗ | assessed | maintain owner-authored profile; maintain evidence-backed profile assertion |
| K10 | Evidence-backed profile assertions retain status, confidence, provenance, validity, and evidence links. | rule/invariant | Profile Pillar lines 17–44 ↗; PIOS profiles ↗ | assessed | maintain evidence-backed profile assertion |
| K11 | A disputed profile assertion requires owner resolution and a versioned outcome. | rule/invariant | Profile Pillar lines 45–55 ↗ | assessed | resolve disputed profile assertion |
| B01 | An Action Tag communicates intended handling but does not execute anything by itself. | rule/invariant | Action Tags lines 15–40 ↗; PIOS taxonomy §10.3 ↗ | assessed | apply an action-intent label |
| B02 | Machine-suggested action intent requires a proposal; automated handling requires a confirmed rule and run evidence. | rule/invariant | Action Tags lines 50–59 ↗; PIOS governing principles ↗ | assessed | apply action-intent label; invoke governed action |
| B03 | An executable action requires explicit permission, logs, and owner visibility appropriate to its effects. | rule/invariant | PIOS taxonomy §10.3 ↗; PIOS Agent Architecture ↗ | assessed | invoke a governed action |
| B04 | Long-running work should release the initiating interface, preserve state, and report durable completion or failure. | recommended default | Action Tags lines 61–81 ↗; PIOS implementation profiles ↗ | assessed | run a background operation |
| B05 | Execution permission is distinct from communication preference and does not override proposal/rule governance. | rule/invariant | PIOS Agent Architecture ↗; PIOS governing principles ↗ | restricted requirement assessed | configure execution policy |
| B06 | Planning, Projects, Routines, To-dos, and Results are user-facing views over distinct execution objects and states, not one capability. | explicit fact | Execution Model lines 17–72 ↗; PIOS Functional Flow ↗ | assessed | B2 boundary context |
| B07 | A Plan is a proposed source design rather than active execution and remains available for review and revision. | rule/invariant | Planning App lines 15–70 ↗; PIOS execution anti-drift rules ↗ | assessed | maintain an execution plan |
| B08 | Activating a Plan creates a Project or Routine while preserving the Plan as the source design record. | rule/invariant | Planning App lines 60–70 ↗; PIOS execution anti-drift rules ↗ | assessed | activate an execution plan |
| B09 | A Project is an active one-off execution container with context, work state, and outputs in progress. | capability purpose | Projects App lines 15–66 ↗; PIOS execution anti-drift rules ↗ | assessed | manage a one-off project |
| B10 | A Routine is reusable execution structure; each concrete use is a distinct run or execution instance. | rule/invariant | Routines App lines 15–58 ↗; PIOS execution anti-drift rules ↗ | assessed | maintain reusable routine; run routine instance |
| B11 | Task is the general actionable unit, while To-do is a standalone task context rather than every task in the system. | rule/invariant | Capability Apps lines 19–32 ↗; PIOS Functional Flow ↗ | assessed | manage an actionable task |
| B12 | A task collection supplies lightweight grouping and ordering without requiring project structure or replacing task identity. | capability purpose | Capability Apps lines 34–45 ↗; PIOS Functional Flow ↗ | assessed | organize a task collection |
| B13 | A reminder has its own trigger, recurrence, snooze, and enabled lifecycle and may attach to another object without becoming that object. | rule/invariant | Capability Apps lines 65–92 ↗; Goals App lines 17–33 ↗ | assessed | schedule a contextual reminder |
| B14 | Canonical work objects hold lifecycle state; chat wrappers and update surfaces communicate but do not replace that state. | rule/invariant | PIOS hybrid work and attention layers ↗ | assessed | all execution-object capabilities |
| B15 | A Work Starter is a ready-to-start entry point carrying enough linked context, next-step guidance, roles, and completion criteria to begin. | capability purpose | PIOS Work Starters ↗ | not applicable | prepare a context-rich Work Starter |
| B16 | Ready work should be ordered by transparent fit to current windows, commitments, context, energy, tools, dependencies, and risk rather than permanent priority labels alone. | recommended default | PIOS Dynamic Scheduling ↗ | not applicable | order ready work for the current context |
| B17 | A reusable workflow package declares inputs, outputs, triggers, parameters, permissions, steps, and safety constraints; published versions are immutable. | rule/invariant | Results App lines 25–35 ↗; PIOS workflow packages ↗ | assessed | maintain a versioned workflow package |
| B18 | An installed workflow is an owner-configured package instance whose enablement, triggers, settings, and version policy are independently governed. | capability purpose | Results App lines 25–37 ↗; PIOS workflow packages ↗ | assessed | manage an installed workflow |
| B19 | A workflow run is one execution with attributable trigger, immutable material input/settings snapshots, steps, outputs, status, errors, and logs. | rule/invariant | Results App lines 30–35 ↗; PIOS workflow packages ↗ | assessed | run a governed workflow |
| B20 | A Result is a produced output or outcome distinct from active execution and retains provenance to its source work, actors, inputs, and time. | rule/invariant | Results App lines 39–47 and 97–101 ↗; PIOS execution anti-drift rules ↗ | assessed | preserve an execution result |
| C01 | The event log is the canonical append-oriented machine record; events preserve stable identity, actor, type, idempotency, source time, and record time. | rule/invariant | PIOS Event Model ↗ | not applicable | record a canonical event |
| C02 | Updates are durable attention items for awareness or response, not canonical truth and not chat entries. | rule/invariant | Updates Pillar lines 15–23 and 80–85 ↗; PIOS hybrid work and attention layers ↗ | assessed | manage an owner attention item |
| C03 | Meaningful completed work should create a linked canonical event, concise update, readable detail, History manifest, and retained evidence reference. | recommended default | PIOS update-first owner History ↗ | not applicable | publish a completed-work record |
| C04 | Daily History prefers structured updates and selected events, uses raw traces for genuine gaps, and assigns entries to an explicit owner day. | recommended default | PIOS update-first owner History ↗ | not applicable | compile daily owner History |
| C05 | Daily summaries may read source events, while weekly and higher summaries compose bottom-up from accepted lower-level summaries. | rule/invariant | Hierarchical Summary lines 15–43 ↗; PIOS update-first owner History ↗ | not applicable | aggregate an owner History period |
| C06 | History exploration is a provenance-preserving time-indexed projection over canonical records, with progressive drill-down rather than a second truth store. | rule/invariant | Unified Timeline lines 102–128 ↗; Timeline and Insights lines 23–41 ↗; PIOS time-zoomable History ↗ | not applicable | navigate time-indexed owner History |
| C07 | A source is the origin context and remains distinct from an import session, retained storage item, and processing job. | rule/invariant | Sources Model lines 19–28 and 48–57 ↗; PIOS source-level processing ↗ | assessed | register a connected source; manage an import session |
| C08 | A connected source requires explicit identity, access method, expected data types, privacy boundary, owner consent, sync state, event mapping, and change/deletion behavior. | rule/invariant | Sources Model lines 34–46 ↗; PIOS connected-source lifecycle ↗ | assessed | register a connected source |
| C09 | An import session is a bounded owner-visible intake event for one or more source items and retains scope, source, progress, and outcome independently from the source itself. | capability purpose | Sources Model lines 48–57 ↗; PIOS source-level processing ↗ | assessed | manage an import session |
| C10 | Basic mapping may be automatic, while deeper enrichment and promotion into retrieval, summaries, profile implications, or owner-facing History require applicable authority and explicit staged handling. | rule/invariant | Import Model lines 19–40 and 51–89 ↗; PIOS source-promotion lifecycle ↗ | assessed | govern source promotion |
| C11 | Ingestion uses separate technical-screen, checklist-readiness, and owner-authorization gates; passing an earlier gate does not grant the authority of a later gate. | rule/invariant | PIOS ingestion gate governance ↗ | not applicable | screen ingestion batch; assess ingestion readiness; authorize ingestion batch |
| C12 | Event types are governed through an owner-scoped registry defining family, schema version, required references, emitter, source of truth, projection effects, lifecycle transition, and approval needs. | rule/invariant | PIOS event-type registry ↗ | not applicable | govern an event-type registry |
| C13 | Operational inspection reads canonical records and logs to explain runs, imports, errors, retries, outputs, and governing evidence without computing new truth in the inspection surface. | rule/invariant | System App lines 45–77 ↗; PIOS System inspection surface ↗ | assessed | inspect an operational run record |
| C14 | A full export is a reconstructable owner-state bundle with stable identities, provenance, manifests, checksums, version information, and rebuild instructions—not merely loose files. | rule/invariant | Export and Portability lines 15–36 and 46–101 ↗; PIOS portability requirement ↗ | assessed | compose a portable Core bundle |
| C15 | Package integrity and compatibility validation are separate from package creation and separately report structure, schema, checksums, provenance, ownership, unsupported content, and uncertainty. | rule/invariant | Export and Portability lines 86–104 ↗; PIOS portability package ↗ | assessed | validate a portability package |
| C16 | Restoring state from a bundle preserves logical identifiers and provenance, rebuilds permitted projections, excludes secrets, and reports accepted, rejected, quarantined, and unresolved content. | rule/invariant | PIOS portability package ↗; PIOS portability requirement ↗ | assessed | restore Core state from a bundle |
| C17 | Exact-byte restoration does not prove operational recovery; destination parity separately checks counts, checksums, protection posture, provenance resolution, owner boundaries, and selected behavior. | rule/invariant | PIOS portability requirement ↗; Core compatibility specification ↗ | not applicable | validate restored Core parity |
| C18 | Versioning is not backup; backup maintenance requires independent creation and protected custody, while restore and parity testing provide separate recovery evidence. | rule/invariant | PIOS backup and recovery ↗ | not applicable | maintain a recoverable Core backup; restore Core state; validate restored Core parity |
| C19 | A governed cutover names the canonical side, bounds any shadow/write-through period, validates destination behavior, applies a final delta, and requires owner approval. | rule/invariant | Core compatibility specification §6 ↗; PIOS portability requirement ↗ | not applicable | govern a Core cutover |
| C20 | Rollback is an explicit alternative outcome when cutover evidence fails or authority is withdrawn; it is not an implicit side effect of migration failure. | rule/invariant | Core compatibility specification §6 ↗ | not applicable | roll back a Core cutover |
| C21 | A source Core is decommissioned only after destination parity and owner sign-off, with retention, deletion, and crypto-shred governance preserved. | rule/invariant | PIOS portability requirement ↗; Core compatibility specification §6 ↗ | not applicable | decommission a source Core |
| C22 | An erasure request is recorded immediately and can stop exposure while physical deletion waits for applicable retention constraints. | rule/invariant | PIOS deletion governance ↗ | not applicable | register an owner-data erasure request |
| C23 | Governed erasure separately removes or expires derived state and completes physical deletion or approved crypto-shredding when permitted, while preserving auditability. | rule/invariant | PIOS deletion governance ↗ | not applicable | execute governed data erasure |
| C24 | Imported connector descriptions do not carry credentials or authority; future synchronization requires separate destination validation and owner authorization. | rule/invariant | PIOS portability package §5 ↗; Core compatibility specification §§5–6 ↗ | assessed | reauthorize a destination connector |
| C25 | A source-composed PIOS Portability Package is assembled from owner-controlled sources independently from a Core export and cannot be represented as existing Core state. | rule/invariant | PIOS portability package §§1–4 ↗ | not applicable | compose a source-derived PIOS portability package |
| D01 | A capture interface submits supported content and source context through a governed intake path; the interface is not a second canonical Core. | rule/invariant | Chrome Extension lines 15–35 ↗; PIOS Core app capture responsibility ↗ | assessed | submit a governed content capture |
| D02 | A submitted capture that lacks confirmed Core acceptance remains pending and needs an explicit accepted, retryable, failed, preserved, or authorized-discard disposition. | reasonable inference | Chrome Extension lines 21–35 ↗; PIOS-native interface boundary ↗ | assessed | reconcile a pending capture |
| D03 | Capture-time action intent and optional processing instructions are separate governed effects; submitting content does not silently execute them. | rule/invariant | Chrome Extension lines 19–35 ↗; PIOS inbound flow ↗ | assessed | capture boundary; existing action/execution capabilities |
| D04 | Onboarding is a staged journey whose progress, pauses, responses, and completion remain explicit rather than being inferred from a single screen or account record. | rule/invariant | Onboarding stages and boundaries ↗; onboarding principles ↗ | assessed | manage a guided onboarding journey |
| D05 | A personal AI's owner-authored presentation identity is distinct from runtime agent roles, owner profile, memory, and execution authority. | rule/invariant | Ally identity and clarifications ↗; historical AI Profile identity boundaries ↗; PIOS agent definition separation ↗ | assessed | maintain a personal AI identity |
| D06 | Interaction preferences may shape communication, explanation, and proposal style but do not change truth status, permissions, or standing authority. | rule/invariant | Historical AI Profile preference boundary ↗ | assessed | configure personal AI interaction preferences |
| D07 | Setup depth and question volume may adapt while sparse optional answers still produce a viable, revisable first configuration with explicit defaults. | rule/invariant | Onboarding alignment and defaults ↗; PIOS metadata flexibility ↗ | assessed | guided onboarding and initial environment preparation |
| D08 | Reply- or challenge-based onboarding verification establishes evidence of contact-point control only; broader identity and authorization remain separate. | rule/invariant | Historical reply-verification requirement ↗; PIOS identity and authorization separation ↗ | assessed with security qualification | verify control of a contact point; onboarding profile |
| D09 | Initial environment preparation distinguishes owner-provided values, defaults, and inferred or provisional context and keeps all of them revisable. | rule/invariant | Onboarding alignment outputs ↗; PIOS context lifecycle ↗ | assessed | prepare an initial owner environment |
| D10 | First entry is a separate authorized transition into a prepared environment; invitation, credential expiry/use, and journey completion remain explicit. | rule/invariant | Invitation and first entry ↗ | assessed | authorize first entry |
| D11 | Restricted requirements and static code evidence do not establish one end-to-end onboarding realization; a bounded first-use orientation surface is not proof of the documented journey. | explicit fact | RAS-01-Z and RAS-01-AB; details withheld | assessed | realization boundary only |
| D12 | Roles are owner-governed context lenses used for filtering and prioritization; they may overlap and must not be treated as access-control grants or runtime agent roles. | rule/invariant | Roles and Modes lines 17–27 and 64–68 ↗; PIOS context dimensions ↗ | assessed | maintain an owner context Role |
| D13 | Role types, specific Role instances, hierarchy relationships, active context, and object assignments are distinct lifecycle claims. | rule/invariant | Roles and Modes lines 19–40 ↗; PIOS Role type and instance ↗ | assessed | Role boundary and reuse |
| D14 | Operating Modes are situational context; persistent Mode definitions require explicit confirmation and remain distinct from activation and task working-mode requirements. | rule/invariant | Roles and Modes lines 46–60 ↗; PIOS Role and Mode lifecycle ↗ | assessed | maintain an owner operating Mode |
| D15 | Active personal context may contain multiple dimensions and sources; inherited or inferred values remain identifiable and incomplete context does not block capture. | rule/invariant | PIOS Active Context and lifecycle ↗ | not applicable | set active personal context |
| D16 | A Role's outward intent is private-first and explicit; it does not itself enforce access, publish content, or expose private Role-linked information. | rule/invariant | Roles and Modes outward dimension ↗; PIOS exposure model ↗ | assessed | configure a Role's outward intent |
| D17 | An outward Role representation is a separate object or copy with source linkage; enabling outward intent must not mutate or reveal the private source. | rule/invariant | Roles and Modes outward knowledge ↗; PIOS outward representation rule ↗ | assessed | prepare a Role-scoped outward representation |
| D18 | Home panels, app menus, split-screen layout, gestures, badges, and context selectors are audience and realization patterns rather than independently meaningful capability outcomes. | explicit fact | Home Panel ↗; App Navigation ↗ | assessed | no separate CRD |
| D19 | Restricted static review supports bounded Role/Mode management and active-filter surfaces but does not establish complete Core-backed context lifecycle, tests, deployment, or availability. | explicit fact | RAS-01-AC through RAS-01-AE; details withheld | assessed | realization boundary only |
| E01 | Observed patterns occupy an intermediate epistemic layer between individual evidence/signals and governed proposals or profile assertions. | rule/invariant | Observed Patterns lines 15–49 ↗; PIOS epistemic sequence ↗ | assessed | pattern capability boundary |
| E02 | Pattern creation requires multiple evidence items, source provenance, a declared threshold, and a non-authoritative emerging state. | rule/invariant | Observed Patterns lines 51–89 ↗ | assessed | detect an observed pattern |
| E03 | The historical application model creates an emerging pattern at three evidence items, but a reusable threshold remains implementation-profile specific. | recommended default | Observed Patterns lines 67–73 ↗ | assessed | detect an observed pattern |
| E04 | Pattern lifecycle tracks recurrence over time through emerging, stable, weakening, and inactive states and preserves snapshots rather than erasing history. | rule/invariant | Observed Patterns lines 78–120 ↗ | assessed | evaluate an observed pattern lifecycle |
| E05 | Only a stable pattern satisfying the declared evidence gate is eligible to generate a proposal; eligibility is not proposal creation or profile confirmation. | rule/invariant | Observed Patterns lines 74–89 and 122–128 ↗; PIOS epistemic sequence ↗ | assessed | evaluate an observed pattern lifecycle |
| E06 | Periodic pattern evaluation is preferred over immediate per-event lifecycle mutation to reduce noise. | recommended default | Observed Patterns stats refresh ↗ | assessed | evaluate an observed pattern lifecycle |
| E07 | Restricted pattern sources declare schemas and planned/disabled inspection or refresh surfaces but do not establish a reachable active detection job, passing tests, deployment, or production behavior. | explicit fact | RAS-01-AH; details withheld | assessed | realization boundary only |
| F01 | Goals preserve longer-horizon direction and may carry time-horizon, focus, lifecycle, and relationship context. | capability purpose | Goals App lines 15–33 ↗; PIOS operational flow ↗ | assessed | maintain an outcome goal |
| F02 | A goal remains a valid named intention without a target, metric, reminder, project, or task. | rule/invariant | Goals App lines 28–33 ↗ | assessed | maintain an outcome goal |
| F03 | Objectives are shorter-horizon, action-oriented statements of direction distinct from longer-horizon goals. | rule/invariant | Goals App lines 78–84 ↗; Planning App lines 17–33 ↗ | assessed | maintain a directional objective |
| F04 | Objectives may guide plan creation, while objective, plan, project, routine, and task lifecycles remain independent. | rule/invariant | Planning App lines 43–70 ↗; PIOS operational flow ↗ | assessed | maintain a directional objective; existing execution capabilities |
| F05 | A target describes measurable or observable success and may exist as a standalone planning object or attach to an eligible subject. | capability purpose | Planning App lines 35–41 ↗; PIOS goals and targets ↗ | assessed | maintain a success target |
| F06 | A target condition is distinct from active state, achievement evidence, a measurement definition, and a current observed value. | rule/invariant | Profile App lines 69–77 ↗; direction and success context | assessed | maintain a success target |
| F07 | A metric definition describes how reality is tracked through fields such as unit and tracking method; it is not itself an observation. | rule/invariant | Goals App lines 28–33 and 54–61 ↗; Profile App lines 69–77 ↗ | assessed | maintain a measurement definition |
| F08 | Metric definitions and metric observations are separate information elements: one defines measurement semantics and the other records time-scoped values. | rule/invariant | Profile Pillar lines 99–108 ↗; PIOS information-object rule ↗ | assessed | maintain a measurement definition; record a metric observation |
| F09 | Goal-to-objective-to-target-to-plan ordering is conceptual guidance rather than a universally enforced schema hierarchy. | explicit fact | Planning App lines 88–98 ↗; PIOS operational flow ↗ | assessed | direction and success boundaries |
| F10 | Restricted static review supports bounded goal, objective, target, and metric-definition persistence plus a declared metric-observation structure, but it does not establish target-achievement evaluation or a reachable metric-observation writer. | explicit fact | RAS-01-AI and RAS-01-AJ; details withheld | assessed | realization boundary only |
| G01 | Canonical private truth and an outward-facing representation remain separate; exposing the representation must not implicitly expose or mutate the source. | rule/invariant | Visibility Model lines 64–80 ↗; PIOS exposure model ↗ | assessed | all outward-representation capabilities |
| G02 | Controlled sharing and public presence are distinct outcomes: one serves bounded audience access, while the other establishes durable public reachability and identity framing. | explicit fact | Visibility Model lines 81–87 ↗; Public Presence lines 37–54 ↗ | assessed | sharing/publication boundary |
| G03 | Publishing is an external action and requires applicable owner authority; an update, notification, draft, or prepared representation is not permission to publish. | rule/invariant | Public Presence lines 152–157 and 173–179 ↗; Integration risk classes ↗; PIOS privacy and access ↗ | assessed | publish a governed outward representation |
| G04 | A controlled share delivers or activates a representation for a bounded audience without making it publicly discoverable or defining the access policy itself. | capability purpose | Public Presence lines 37–75 ↗; PIOS Core and Circle ↗ | assessed | share a governed outward representation |
| G05 | Visibility, discovery, access control, and usage rights are independent axes and must not be collapsed into one public/private flag. | rule/invariant | Visibility Model lines 19–62 ↗; PIOS exposure model ↗ | assessed | outward exposure boundary |
| G06 | Publicly reachable content may remain hidden or unlisted, while indexed or promoted discovery requires a separate state and handling. | rule/invariant | Visibility Model lines 39–47 ↗; Public Presence lines 45–64 ↗ | assessed | govern outward discoverability |
| G07 | Usage rights may distinguish human viewing/reuse from crawler, agent, indexing, training, redistribution, attribution, and commercial-use permissions. | rule/invariant | Public Presence lines 77–110 ↗; PIOS exposure model ↗ | assessed | govern outward usage rights |
| G08 | Access policies and audience grants are maintained separately from discoverability and usage rights, and revocation does not erase required evidence or canonical source state. | rule/invariant | Visibility Model lines 49–62 and 118–132 ↗; Integration lifecycle and revocation ↗ | assessed | maintain outward access policy |
| G09 | Publishing maintains first-class revision and lifecycle evidence for creation, update, republish, archive, and revoke actions. | rule/invariant | Public Presence lines 112–147 and 185–195 ↗ | assessed | publish a governed outward representation |
| G10 | A bounded search of the selected restricted application revision did not identify the searched public-asset, sharing, visibility, discovery, or rights implementation model. | explicit fact | RAS-01-AK; details withheld | assessed | realization boundary only |
| G11 | Applying the current access policy to one request produces an attributable allow or deny decision without changing the policy. | capability purpose | Visibility Model lines 49–62 and 118–132 ↗; Integration enforceable authorization ↗ | assessed | evaluate an outward access request |
| H01 | Reviews are first-class Knowledge concepts with daily, weekly, monthly, yearly, and event-triggered forms and explicit questions, reviewed inputs, decisions, updates, and carry-forward items. | capability purpose | PIOS Knowledge concept catalog ↗ | not applicable | conduct a structured review |
| H02 | Review fits the continuous operating loop after execution and before adjustment. | explicit fact | PIOS continuous adjustment loop ↗ | not applicable | conduct a structured review |
| H02A | Normal operation should reduce dependence on heavy catch-up reviews. | recommended default | PIOS continuous adjustment loop ↗ | not applicable | conduct a structured review |
| H03 | A review can produce a durable note and updates through a governed workflow, while the workflow package and run remain separate capabilities. | implementation choice | Results App lines 74–83 ↗ | assessed | structured review; existing workflow capabilities |
| H04 | Review outcomes may carry unresolved work forward or propose changes, but those downstream objects and transitions retain their own identities and authority. | rule/invariant | PIOS Today View and continuous adjustment loop ↗ | not applicable | structured review boundary |
| H05 | A summary compresses known material, while a reflection is interpretive review containing judgment, open loops, residue, and recommendations. | rule/invariant | PIOS clarity terms ↗ | not applicable | record a reflective assessment |
| H06 | Temporal summaries may become increasingly reflective at broader periods, but summary and reflection remain distinguishable information objects. | explicit fact | Hierarchical Summary lines 80–90 ↗; PIOS clarity terms ↗ | assessed | summary/reflection boundary |
| H07 | Restricted static review finds a manual weekly-review workflow that reads bounded recent material, invokes a model, creates a note, and records a workflow output; it does not establish the documented schedule, a canonical review object, structured decisions/carry-forward, tests, deployment, or production behavior. | explicit fact | RAS-01-AL; details withheld | assessed | realization boundary only |
| I01 | Human/contact profiles describe other people in the owner's world and remain distinct from owner, agent, and asset profiles. | explicit fact | PIOS Knowledge profile families ↗ | not applicable | maintain a human contact profile |
| I02 | A human contact profile may include identity, aliases, descriptive context, relationship references, consent, and source-linked history without replacing dynamic interactions. | capability purpose | PIOS Knowledge profile families ↗; Contacts App lines 15–43 ↗ | assessed | maintain a human contact profile |
| I03 | Slowly changing relationship/profile attributes should preserve source references and review time, while dynamic interactions remain linked events or relationship records. | recommended default | PIOS Knowledge profile lifecycle ↗ | not applicable | contact and relationship boundaries |
| I04 | Glossary person identity and a contact profile overlap but serve different purposes: one stabilizes entity meaning and aliases, while the other records the owner's practical relationship knowledge. | explicit fact | Contacts App lines 82–90 ↗; PIOS glossary and Knowledge ↗ | assessed | person identity/contact-profile boundary |
| I05 | Contact points are typed communication or location coordinates attached to a contact profile and may carry labels and normalization state. | capability purpose | Contacts App lines 45–58 ↗ | assessed | maintain a contact point |
| I06 | Storing or normalizing a contact point does not establish current control, legal identity, permission to communicate, or broader authorization. | rule/invariant | people and relationships context; PIOS profile authority separation ↗ | assessed | contact point and verification boundary |
| I07 | Contact-point control verification is an evidence-bearing state distinct from maintaining the contact value; onboarding verification is one scoped specialization. | rule/invariant | D08 in this ledger; people and relationships context | assessed with security qualification | verify control of a contact point |
| I08 | Relationship context describes how the owner relates to another person or organization through relationship type, Circle scope, trust, consent, roles, history, and interaction context. | capability purpose | PIOS Knowledge profile families ↗; PIOS people and relationships family ↗ | not applicable | maintain personal relationship context |
| I09 | Temporary with-whom context records how a person or organization relates to one event or session and does not replace a durable relationship record. | explicit fact | PIOS with-whom taxonomy ↗ | not applicable | relationship and active-context boundaries |
| I10 | Relationship scope, trust, Role assignment, and contextual classification do not themselves grant access to information. | rule/invariant | PIOS Core and Circle ↗; PIOS context-tag lifecycle ↗ | not applicable | maintain personal relationship context |
| I11 | Restricted static review supports contact-profile and contact-point create/read/update/delete behavior, but verification, primary-point selection, and richer relationship-origin lifecycle are declared or incomplete rather than confirmed reachable behavior. | explicit fact | RAS-01-AM and RAS-01-AN; details withheld | assessed | realization boundary only |
| J01 | Persistent agents are first-class governed System information with human-visible and agent-readable profiles. | rule/invariant | PIOS agent architecture ↗ | not applicable | maintain an agent definition |
| J02 | An agent definition includes purpose, role, responsibilities, skills, permissions, memory scope, source access, operating instructions, current state, and evolution history. | capability purpose | PIOS agents as first-class information ↗ | not applicable | maintain an agent definition |
| J03 | Agent definition, runtime, owner-governed memory, and activity are distinct; replacing a runtime does not replace the definition or canonical memory. | rule/invariant | Integration agent separation ↗; PIOS agent architecture ↗ | not applicable | agent definition/runtime boundary |
| J04 | Runtime copies derive from canonical agent definitions and require source version, target, synchronization state, history, and rollback visibility. | rule/invariant | PIOS agents as first-class information and profile surface ↗; PIOS governance of agent definitions ↗ | not applicable | synchronize an agent definition to runtime |
| J05 | Director, manager, and worker are functional runtime roles, while peer is a relationship and recovery is a temporary mode. | explicit fact | Agent Roles lines 15–52 ↗ | assessed | assign an agent runtime role |
| J06 | Runtime-role assignment and coordination must preserve agent identity, actor attribution, permission scope, and temporary-work boundaries. | rule/invariant | PIOS agent layers and responsibilities ↗; Agent Roles lines 27–48 ↗ | assessed | assign an agent runtime role |
| J07 | Acting outward under the owner's identity, as a disclosed personal AI, or as a purpose-built AI representative creates different identity and trust conditions. | rule/invariant | Outward Identity Modes lines 15–28 ↗ | assessed | select an agent's outward identity |
| J08 | The owner explicitly chooses the outward identity mode; no mode is a technical default, and undisclosed AI representation requires especially clear authority. | rule/invariant | Outward Identity Modes lines 119–128 ↗; PIOS owner authority ↗ | assessed | select an agent's outward identity |
| J09 | Outward identity selection does not itself authorize or execute the message, publication, transaction, or other external action. | rule/invariant | PIOS integration risk classes ↗; agents and outward identity context | not applicable | outward identity/action boundary |
| J10 | An owner-representative AI uses a purpose-specific identity and dedicated owner-curated knowledge scope to converse with an external audience. | capability purpose | AI Twins lines 15–33 and 41–60 ↗ | assessed | conduct an owner-representative conversation |
| J11 | A representative's audience, access, channel, and knowledge scope remain governed independently, and private personal-AI or Core context is not implicitly available. | rule/invariant | AI Twins lines 51–97 ↗; PIOS exposure model ↗ | assessed | representative conversation and outward governance |
| J12 | AI Twin is a composed outward product realization rather than one indivisible generic capability. | explicit fact | AI Twins lines 87–110 ↗; agents and outward identity context | assessed | no standalone AI-Twin CRD |
| J13 | Restricted assessment did not identify canonical agent-definition, runtime-sync, AI-Twin, or representative-conversation models; selected personal-AI and Role-intent controls do not establish those broader capabilities. | explicit fact | RAS-01-AO and RAS-01-AP; details withheld | assessed | realization boundary only |
| L01 | Circle-style collaboration is a visible, replaceable coordination layer around active work rather than the source of execution or personal-memory truth. | explicit fact | Circle lines 17–38 ↗; PIOS example agent harness ↗ | not applicable | collaboration objects and canonical-state boundary |
| L02 | A collaboration channel is a top-level organizer with stable identity, participant/visibility scope and archival lifecycle; threads belong to channels and archived channels are not hard-deleted. | capability purpose | Circle lines 50–65 ↗ | assessed | maintain a collaboration channel |
| L03 | Channel organization must not replace work-object state, execution truth or topical knowledge organization. | rule/invariant | Circle lines 23–38 ↗; Circle lines 134–150 ↗; PIOS Circle and Core boundaries ↗ | assessed | maintain a collaboration channel |
| L04 | A discussion thread is a focused conversation linked to a message, work object, run, result, file, note or exception. | capability purpose | Circle lines 66–74 ↗ | assessed | maintain a work-linked discussion thread |
| L05 | Thread lifecycle and depth are governed independently from the linked object's lifecycle; the historical profile uses open, waiting, blocked, resolved and archived states with one-level branching. | rule/invariant | Circle lines 66–74 ↗; Hybrid Work Model lines 89–101 ↗ | assessed | maintain a work-linked discussion thread |
| L06 | Resolving or archiving a discussion does not silently resolve, replace or mutate the canonical work object it references. | rule/invariant | Circle lines 134–166 ↗ | assessed | thread/work-object boundary |
| L07 | A collaboration message preserves author identity, time, body, type, context and linked references as one attributable communication. | capability purpose | Circle lines 75–93 ↗ | assessed | record an attributed collaboration message |
| L08 | Agents and systems must preserve true actor identity and cannot silently impersonate the owner or another participant. | rule/invariant | Circle lines 75–84 ↗; Circle lines 176–180 ↗; PIOS agent harness identity controls ↗ | assessed | record an attributed collaboration message |
| L09 | Agent-triggering messages require explicit reply permission and bounded conversation, parent, origin, hop, turn, grant and execution metadata. | rule/invariant | PIOS loop-control requirements ↗ | not applicable | attributed message and orchestration reuse |
| L10 | Inbound message text, attachments and links are untrusted data and cannot modify policy, hidden instructions, tool permissions or owner-only capabilities without separate checks. | rule/invariant | PIOS communication-harness security boundary ↗ | not applicable | record an attributed collaboration message |
| L11 | A task-scoped execution workspace is a runtime work area distinct from a user-facing project and canonical home. | explicit fact | Execution Workspace lines 15–21 ↗; Execution Workspace lines 36–43 ↗ | assessed | manage a task-scoped execution workspace |
| L12 | Workspace working copies, temporary state, context, intermediate outputs and operational shadow state follow a provision, disposition and cleanup lifecycle. | capability purpose | Execution Workspace lines 23–34 ↗ | assessed | manage a task-scoped execution workspace |
| L13 | Restricted static review found channel-like filters and an owner-to-assistant message flow but did not confirm the richer linked-thread, attributed-agent-message or execution-workspace models. | explicit fact | RAS-01-AQ and RAS-01-AR; details withheld | assessed | realization boundary only |
| N01 | Personal conversation history preserves a continuing episodic record of owner-system interaction while most conversation remains distinct from deliberate notes and other canonical objects. | capability purpose | Chat History Pillar lines 15–22 ↗; PIOS source and event model ↗ | assessed | maintain personal conversation history |
| N02 | Channels, threads and topic splits can organize or filter conversation continuity without requiring unrelated physical histories. | implementation choice | Chat History Pillar lines 23–34 ↗ | assessed | conversation-history organization |
| N03 | Hiding or deletion state must not silently rewrite what occurred in conversation history. | rule/invariant | Chat History Pillar lines 35–37 ↗; PIOS event-log principles ↗ | assessed | maintain personal conversation history |
| N03A | Conversation corrections should preserve prior evidence. | recommended default | Chat History Pillar lines 35–37 ↗ | assessed | maintain personal conversation history |
| N04 | Conversation history, deliberate notes, owner attention updates, canonical work state, and curated owner-facing History remain distinct. | explicit fact | Chat History Pillar lines 95–107 ↗; PIOS hybrid work and attention layers ↗ | assessed | conversation-history boundary |
| N05 | Imported conversation material may join personal history only with preserved source identity, attributable ownership and credible time context; ambiguous admission requires owner review. | rule/invariant | Imported History lines 17–58 ↗ | assessed | source promotion and conversation-history membership |
| N06 | Storage, mapping, conversation-history inclusion, retrieval, summary use and pattern/profile influence are independently governed states. | explicit fact | Imported History lines 70–105 ↗; PIOS source promotion ↗ | assessed | reuse existing intake, promotion, retrieval, summary, pattern and proposal capabilities |
| N07 | Restricted static review found an owner-linked history, paired interaction entries, filters, session markers, recent-context assembly and a read-only history view, but not the complete reusable contract. | explicit fact | RAS-01-AS; details withheld | assessed | realization boundary only |
| N08 | Owner-facing conversational, structured, collaboration and operational views are interface roles over the personal information system, not canonical stores of truth. | explicit fact | Personal Interfaces lines 15–47 ↗; PIOS Core app and interface role ↗ | assessed | personal-interface composition |
| N09 | Primary, secondary, master and fallback access paths distinguish day-to-day, collaboration, administration, recovery and continuity roles. | capability purpose | Personal Interfaces lines 49–68 ↗ | assessed | maintain an owner access path |
| N10 | App grids, panels, dashboard sections, gestures and remembered views are realization or audience patterns; access-path governance is independent from interface layout and domain authorization. | explicit fact | Home Panel lines 15–59 ↗; App Navigation lines 15–112 ↗; PIOS interface boundary ↗ | assessed | no panel or navigation CRD |
| Q01 | A PIOS-native owner interface may support local-first capture, offline staging, disconnected use, and non-canonical device caches while remaining replaceable by another authorized interface. | explicit fact | PIOS-native interface boundary ↗ | not applicable | device cache, offline staging, and owner access paths |
| Q02 | Shared local storage, caches, staging stores, and projections do not become canonical Core merely through proximity or reuse. | rule/invariant | PIOS-native interface boundary ↗; same-publisher and local-substrate profiles ↗ | not applicable | cache/offline/pending-work boundary |
| Q03 | Each application or runtime using a shared local substrate retains distinct identity, declared grants, technical scopes, audit attribution, and revocable access. | rule/invariant | Same-publisher and local-substrate profiles ↗ | not applicable | maintain an authorized device-local content cache |
| Q04 | Any offline synchronization profile must define canonical side, conflict, idempotency, correction, revocation, deletion, and cutover behavior before writable operation. | rule/invariant | Same-publisher and local-substrate profiles ↗ | not applicable | cache and offline reconciliation |
| Q05 | Detailed recent-cache, selected-offline, freshness, eviction, and disconnected-revocation semantics are not fixed by the committed baseline. | unknown/unresolved | PIOS-native interface boundary ↗; same-publisher and local-substrate profiles ↗ | not applicable | device-cache and offline-content profiles |
| Q06 | A personal reading queue presents retained captured articles for focused reading without storing the source content independently. | capability purpose | Reader App lines 15–23 ↗ | assessed | manage a personal reading queue |
| Q07 | The historical reading model distinguishes feed, unread, saved and archive views over source-linked items. | implementation choice | Reader App lines 25–43 ↗ | assessed | reading-queue state |
| Q08 | Reader presentation, typography, scroll behavior and application layout are realization choices rather than separate capabilities. | explicit fact | Reader App lines 21–34 and 44–56 ↗ | assessed | no Reader-interface CRD |
| Q09 | AI-organized reading topics reuse contextual classification or assisted-label capabilities; generated summaries and PDF copies reuse derivation and retention capabilities. | reasonable inference | Reader App lines 25–43 ↗; device continuity and reading context | assessed | reuse existing capabilities |
| Q10 | Restricted static review supports a Reader path over retained items with read and saved states, but its admission, completion, durable-save and topic-membership behavior does not fully match the historical design. | explicit fact | RAS-01-AU; details withheld | assessed | realization boundary only |
| Q11 | No complete restricted realization of the current PIOS device-cache or selected-offline-content contracts was confirmed. | explicit fact | RAS-01-AV; details withheld | assessed | realization boundary only |
| R01 | Cost governance is a product permission and control concern for resource-intensive work, not automatically a billing system. | explicit fact | Cost and Credit Governance lines 15–34 ↗; PIOS deployment-cost boundary ↗ | assessed | cost and resource governance |
| R02 | Estimate, approval, reservation, spend, partial/full completion and final accounting are distinct stages with different outcomes. | explicit fact | Cost and Credit Governance lines 36–51 ↗ | assessed | decomposition across capabilities and reuse |
| R03 | A useful estimate identifies the bounded operation and communicates a meaningful range, class, depth or alternative scope without false precision. | capability purpose | Cost and Credit Governance lines 53–71 ↗ | assessed | estimate operation resource cost |
| R04 | Costly or high-impact actions require explicit request-scoped approval unless applicable standing authority already covers the exact class. | rule/invariant | Cost and Credit Governance lines 73–98 ↗; PIOS guarded-action approval ↗ | assessed | reuse proposal, standing-rule and execution-policy capabilities |
| R05 | A reservation temporarily holds the expected internal resource amount before or during execution and remains distinct from actual consumption. | capability purpose | Cost and Credit Governance lines 36–51 and 149–157 ↗ | assessed | reserve an operation resource budget |
| R06 | Budget and processing-depth choices constrain execution scope, while most-relevant-first, subset-first, sample-first and map-only are selectable execution strategies. | implementation choice | Cost and Credit Governance lines 100–119 ↗ | assessed | execution policy and contextual ordering reuse |
| R07 | Resource approval and standing preferences reuse governed proposal, explicit request, action-intent, standing-rule and execution-policy mechanisms rather than creating a parallel authority model. | reasonable inference | Cost and Credit Governance lines 73–98 ↗; cost and resource-governance context | assessed | reuse existing governance capabilities |
| R08 | Budget- or approval-constrained partial completion is valid and must identify completed scope, remaining work and additional resource needs. | rule/invariant | Cost and Credit Governance lines 121–135 ↗ | assessed | background operation and resource reconciliation |
| R09 | Final accounting preserves actual use and any variance from the reservation or estimate. | capability purpose | Cost and Credit Governance lines 36–51 ↗ | assessed | reconcile operation resource usage |
| R10 | Actual resource consumption can reuse attributable metric observations, while reconciliation remains the separate operation-level outcome. | reasonable inference | cost and resource-governance context; metric observation CRD | not applicable | metric-observation reuse |
| R11 | Restricted assessment found retrieval token-budget requirements but did not confirm a generic estimate, reservation, spend-accounting or reconciliation realization. | explicit fact | RAS-01-AW; details withheld | assessed | realization boundary only |
| S01 | Source discovery is a candidate-only phase before connector/source registration and does not create a second collection path. | explicit fact | Cognitive Memory companion lines 7–24 and 67–89 ↗ | not applicable | discover a candidate information source |
| S02 | Discovery may inspect a submitted domain, page, organization or service for potential feeds, APIs, sitemaps, public release channels or other update sources. | capability purpose | Cognitive Memory companion, source discovery ↗ | not applicable | discover a candidate information source |
| S03 | A discovery record retains submitted subject, candidate type/location, confidence, expected frequency, security/authentication state, terms/robots notes, likely cost, actor and time. | rule/invariant | Cognitive Memory companion, discovery record ↗ | not applicable | source-discovery candidate record |
| S04 | Discovery, candidate review, permission review, registration, backfill authorization and incremental collection authorization are separate transitions. | rule/invariant | Cognitive Memory companion, source-discovery state machine ↗ | not applicable | source lifecycle decomposition |
| S05 | A source is origin context and remains distinct from an import session, storage item and processing job. | explicit fact | Sources Model lines 19–32 and 48–57 ↗ | assessed | source discovery and registration boundary |
| S06 | Owner implementation documentation exists to make the actual system understandable, navigable, configuration-visible and directly editable without exclusive dependence on apps or agents. | capability purpose | Knowledge Environment lines 15–28 ↗ | assessed | maintain owner implementation documentation |
| S07 | Neutral framework documentation and owner-specific implementation documentation remain intentionally separate. | rule/invariant | Knowledge Environment lines 29–38 ↗ | assessed | maintain owner implementation documentation |
| S08 | Vault names, folder structures, aliases, shared-folder sync and Obsidian are historical realization patterns rather than universal capability requirements. | explicit fact | Knowledge Environment lines 40–95 and 140–171 ↗; source-discovery and owner-knowledge context | assessed | no vault/sync CRD |
| S09 | Agent behavior files and system-required configuration filenames remain governed runtime/agent definitions; documentation may expose them by reference without becoming their canonical source automatically. | explicit fact | Knowledge Environment lines 173–233 ↗; PIOS agent definitions ↗ | assessed | implementation documentation and agent-definition boundary |
| S10 | The authoritative relationship among local knowledge documentation, Personal Cloud/Core state and synchronized copies remains unresolved. | unknown/unresolved | Knowledge Environment lines 284–290 ↗ | assessed | implementation-documentation profile |
| S11 | Knowledge Compilation is ongoing PIOS-native work that maintains source notes, concepts, entities, summaries, backlinks, indexes, contradictions, synthesis and maintenance flags. | explicit fact | PIOS Knowledge Compilation ↗ | not applicable | knowledge maintenance composition |
| S12 | Knowledge integrity assessment covers structural, evidence, meaning and safety defects such as orphan links, missing sources, unresolved contradictions and incorrect exposure. | capability purpose | PIOS Knowledge Maintenance and Linting ↗ | not applicable | assess knowledge-layer integrity |
| S13 | Knowledge maintenance should normally produce flags, proposals and review tasks rather than silently rewriting important knowledge. | recommended default | PIOS Knowledge Maintenance and Linting ↗ | not applicable | assess knowledge-layer integrity |
| S14 | Dataview orphan, connectivity, source and staleness queries are realization tools for integrity assessment, not capabilities themselves. | explicit fact | Dataview Queries lines 98–139 ↗ | assessed | knowledge-integrity realization tools |
| S15 | Restricted assessment did not identify candidate source-discovery, owner implementation-documentation lifecycle, or knowledge-linting realizations. | explicit fact | RAS-01-AX and RAS-01-AY; details withheld | assessed | realization boundary only |
| T01 | Meaning answers why a source, event, decision, or experience matters to the owner and remains a contextual, revisable interpretation. | capability purpose | Cognitive Memory companion, object families ↗ | not applicable | maintain a personal Meaning record |
| T02 | Learning records an evidence-linked lesson, preference, strategy, correction, warning, or working method that may help later. | capability purpose | Cognitive Memory companion, object families and record contracts ↗ | not applicable | maintain evidence-linked Learning |
| T03 | Meaning and Learning are Knowledge objects rather than another data zone, private model memory, profile truth, or automatic policy. | explicit fact | Cognitive Memory companion, object families ↗ | not applicable | both cognitive-memory capabilities |
| T04 | Meaning and Learning retain subject/evidence references, source events, statement, originator/model, confidence, context, creation, status, and revision relationships. | rule/invariant | Cognitive Memory companion, required fields ↗; record contracts ↗ | not applicable | Meaning and Learning shared records |
| T05 | Machine-generated Meaning or Learning starts proposed and cannot silently change Cotton, profile truth, rules, skills, agent behavior, policy, or ranking. | rule/invariant | Cognitive Memory companion, non-authoritative lifecycle ↗ | not applicable | Meaning and Learning lifecycle |
| T06 | Observation, interpretation, Meaning, and Learning remain separate epistemic outcomes and no stage promotes itself automatically. | explicit fact | Cognitive Memory companion, non-authoritative lifecycle ↗; epistemic lifecycle ↗ | not applicable | cognitive-memory decomposition |
| T07 | A Meaning interface is a projection over governed knowledge and evidence rather than a new authority, zone, or permission source. | explicit fact | Cognitive Memory companion, record contracts ↗ | not applicable | no Meaning-service CRD |
| T08 | Recalling confirmed Meaning or Learning and adapting future behavior are separate; adaptation requires its own governed decision. | rule/invariant | Cognitive Memory companion, record contracts ↗; epistemic lifecycle ↗ | not applicable | Learning and adaptation boundary |
| T09 | A retained derived representation identifies source/version, logical Core reference, processing profile/model/version, confidence/status, sensitivity, consent, retention, deletion/revocation behavior, creation, and provenance. | rule/invariant | Cognitive Memory companion, derived representation record ↗ | not applicable | govern derived-representation lifecycle |
| T10 | Text chunks, metadata, graph snapshots, OCR, vectors, summaries, and retrieval indexes are representation types; provider paths and payload keys are implementation metadata rather than canonical meaning. | explicit fact | Cognitive Memory companion, derived representation record ↗ | not applicable | representation-type profiles |
| T11 | Source-local graph snapshots preserve source-version claims, evidence, confidence, and ambiguity before global resolution. | rule/invariant | Cognitive Memory companion, source-local graph snapshots ↗ | not applicable | graph-snapshot representation profile |
| T12 | A derived-representation registry tracks identity, lifecycle status, replacement, authorization, retention, and provider-specific physical reference. | capability purpose | Cognitive Memory companion, registry and lifecycle ↗ | not applicable | govern derived-representation lifecycle |
| T13 | Incompatible model, dimension, modality, format, or semantic-space outputs retain separate identities and a new output does not silently overwrite the only historical representation. | rule/invariant | Cognitive Memory companion, registry and lifecycle ↗ | not applicable | representation identity |
| T14 | Representation support requires evidence for source linkage, versioning, retrieval provenance, revocation/deletion, and fail-closed exclusion behavior. | rule/invariant | Cognitive Memory companion, required future evidence ↗ | not applicable | realization qualification |
| T15 | Historical design treats human-readable canonical information, knowledge-graph projections, and vector projections as complementary layers. | explicit fact | Unified Personal Core lines 35–43 ↗ | assessed | derived-representation profiles |
| T16 | Historical operations design names missing-embedding checks and embedding-refresh jobs without proving one implementation. | explicit fact | System application lines 55–73 ↗ | assessed | representation maintenance profile |
| T17 | Restricted assessment found no Cognitive Memory Meaning/Learning lifecycle and only an early embedding shape that was later removed, with no reachable retained writer or registry lifecycle confirmed. | explicit fact | RAS-01-AZ and RAS-01-BA; details withheld | assessed | realization boundary only |
| V01 | A canonical home is the designated logical source of truth for an information or execution-object class. | explicit fact | Canonical Home lines 15–31 ↗ | not applicable | canonical-state target |
| V02 | Working copies and temporary execution state remain distinct from authoritative durable versions. | rule/invariant | Canonical Home lines 21–29 ↗ | not applicable | artifact-promotion boundary |
| V03 | Crossing from an execution workspace to canonical state is an explicit promotion with review and approval state rather than silent persistence. | capability purpose | Canonical Home lines 33–48 ↗; Governance Principles lines 27–42 ↗ | assessed | promote a working artifact to canonical state |
| V04 | A promoted artifact is not necessarily a user-facing Result, and a Result is not the universal definition of promotion. | explicit fact | Canonical Home lines 50–57 ↗ | assessed | promotion and result separation |
| V05 | Current PIOS requires every representation to retain source/version provenance, lifecycle status, and authority and prohibits one representation from silently promoting another into canonical truth. | rule/invariant | PIOS governing principles ↗ | not applicable | canonical promotion and derived representation |
| V06 | Shared-workspace value depends on AI outputs becoming inspectable owner-held information rather than remaining transient assistant-only context. | explicit fact | Shared Workspace lines 15–31 ↗ | assessed | promotion and retention composition |
| V07 | Historical application state, navigation, UI standards, terminology mappings, area indexes, market pages, and logs are implementation, audience, documentation, or project context rather than independent owner-domain capabilities. | reasonable inference | historical corpus disposition | assessed | no additional CRDs |
| V08 | Restricted assessment did not identify the named canonical-home, promotion-boundary, working-copy, or promoted-artifact realization. | explicit fact | RAS-01-BB; details withheld | assessed | realization boundary only |