| U01 | When, if ever, may a processing realization enrich a source object in place rather than create a separately identified derivative? | Historical design and current state principles favor explicit source/derivative identity; realization-specific evidence is not publishable. | final derivative contract policy, not pilot publication |
| U02 | What receipt-retention period is required for retrieval at different risk levels? | Current PIOS establishes provenance and context receipts but not one universal duration. | later governance profile |
| U03 | Which pilot capabilities have publicly verifiable operational realizations? | The assessed application evidence is restricted and static evidence does not prove deployment. | realization claims only |
| U04 | Which standing-rule non-match decisions require durable logging? | Risk and volume can differ; admitted sources do not establish a universal rule. | later execution profile |
| U05 | Is active-session context selection one capability or several scope-specific capabilities? | The sources distinguish active context from attaching context to durable objects, but the full interaction contract has not yet been extracted. | A2/context continuation |
| U06 | What universal contract governs assigning an owner-confirmed organizing label to an object? | Vocabulary management and assignment are independently meaningful; this pass covered only vocabulary management. | later knowledge/context pass |
| U07 | Which assisted-label vocabulary changes require direct owner confirmation versus a standing rule? | Source generations differ in how much direct user creation or AI curation they allow. | governance profile |
| U08 | What authority model governs profile assertions about people other than the Core owner? | Current PIOS distinguishes owner and relationship profiles, but the full consent contract is outside this tranche. | relationship/profile tranche |
| U09 | Should assigning a structured behavior to a note become a generic capability or remain an implementation composition pattern? | Current evidence primarily describes app tables and hooks rather than one durable cross-implementation outcome. | actions/execution tranche |
| U10 | Do the A2 note/profile requirements have reachable implementation paths at the selected restricted revision? | Required blobs were absent from the existing partial checkout and could not be retrieved during this cycle. | realization evidence only; CRD source analysis may continue |
| U12 | What universal precedence applies when execution policy, a standing rule, and request-scoped approval overlap? | Sources establish all three controls but not one complete cross-profile precedence table. | governance alignment |
| U13 | Do the B2 execution-object requirements have reachable implementation paths at the selected restricted revision? | The relevant paths are named in the source tree, but their blobs are unavailable in the existing partial checkout and remote retrieval is currently unavailable. | realization evidence only |
| U14 | What compatibility contract allows a Routine to reference, derive from, or be exported as a Workflow Package? | The capability boundary is now explicit, but safe conversion and version linkage are not specified. | later interoperability tranche |
| U15 | Which changes in contextual work ordering may be automatic, and which require an explicit owner decision? | Current PIOS supports dynamic replanning but does not define one universal authority profile for moving, splitting, delegating, or deferring work. | execution-governance profile |
| U16 | What qualifies an execution output as a retained Result rather than ordinary operational data? | Sources distinguish produced value from generic storage but do not define one universal materiality threshold. | result-retention profile |
| U17 | What universal event-family registry and lifecycle schemas are required beyond the minimal event envelope? | Current PIOS requires registry governance but intentionally leaves family-specific fields and transitions extensible. | later event-governance profile |
| U18 | How should late-arriving events revise a closed daily or higher-period History entry? | Sources require honest provenance and closure but do not establish one correction/republication policy. | History versioning profile |
| U19 | Which completed outcomes cross the meaningful-work threshold for mandatory update-first publication? | Current PIOS gives examples and principles but not one universal materiality rule. | completed-work publication profile |
| U20 | Which source classes may use automatic baseline mapping, and what confidence threshold applies? | Current sources establish the baseline/deeper distinction but leave source-specific profiles open. | source-processing profile |
| U21 | Which ingestion risks require independent human peer screening rather than an agent-only technical screen? | The gate roles are defined, but reviewer independence varies by sensitivity and consequence. | ingestion-governance profile |
| U22 | How are event-type schema changes classified as compatible, migration-requiring, or prohibited? | Registry governance is required, but one cross-family compatibility policy is not defined. | event-registry profile |
| U23 | What retention and redaction rules apply to operational run evidence across sensitivity classes? | Inspection requires source evidence, while logs may contain sensitive inputs, errors, or model/tool details. | operations profile |
| U24 | Which signing and encryption profiles are mandatory for each portability-package class? | Sources require integrity and protected handling but leave universal algorithms and trust roots open. | portability security profile |
| U25 | What merge and rollback semantics apply when a bundle is restored into an existing non-empty Core? | Conflicts must not silently overwrite state, but object-family-specific resolution is not complete. | restore profile |
| U26 | What minimum behavior suite proves complete PIOS recovery for each implementation profile? | Current PIOS separates state restore, Core conformance, and service recovery but does not freeze one universal suite. | parity profile |
| U27 | What recovery-point, recovery-time, retention, and restore-test cadence applies to each deployment profile? | Backup and restore testing are required, while service-level objectives remain implementation-specific. | recovery profile |
| U28 | What stabilization period and evidence are required before source decommissioning? | Cutover and parity gates are defined, but one universal observation window is not. | cutover profile |
| U29 | How are destination-only writes reconciled during rollback? | The compatibility specification requires reconciliation but leaves object-family conflict rules open. | rollback profile |
| U30 | What minimal tombstone metadata may remain after erasure across different legal and retention regimes? | Auditability and deletion must coexist, but the universally permissible residue is not defined. | erasure profile |
| U31 | Which connector classes can be reauthorized without renewed interactive owner consent? | Credentials and authority cannot be imported, while provider consent mechanisms differ. | connector profile |
| U32 | Which payload-size, media-class, encryption, and offline-packaging profiles apply to governed captures? | The capability requires integrity and safe handoff, while device and transport constraints are implementation-specific. | capture profile |
| U33 | What retry, retention, conflict, and storage-pressure policy protects pending captures that may contain unique unconfirmed work? | The draft capability requires an explicit disposition but the committed framework does not establish one universal device policy. | pending-capture profile |
| U34 | Which contact-verification methods and assurance levels are acceptable for each onboarding and deployment profile? | A reply can demonstrate some channel control but may not satisfy higher-risk identity, account, or recovery requirements. | onboarding security profile |
| U35 | When may parsed onboarding answers or defaults become owner-confirmed role, mode, preference, or profile state? | Sources require forward progress and structured output but do not define one universal promotion rule for every data class. | onboarding governance profile |
| U36 | What minimum schema and portability contract applies to personal-AI identity and interaction preferences? | The concepts are reusable, while supported fields, presentation assets, and preference vocabularies vary by implementation. | agent-definition portability profile |
| U37 | How does first-entry authorization bind to persistent account identity, later authentication, and account recovery? | First entry is bounded, while long-term identity and recovery differ by deployment and service model. | identity/account profile |
| U38 | How should onboarding dialogue continue as canonical conversation and History without duplicating or rewriting source communication? | Continuity is required, but source-message preservation, conversation projection, and first-entry presentation remain separate concerns. | onboarding continuity profile |
| U39 | What portable identity and relationship rules map Role types and Role instances across Core implementations? | Current PIOS distinguishes the levels but does not freeze universal identifiers, hierarchy constraints, or merge semantics. | Role interoperability profile |
| U40 | Which active-context values synchronize across devices, how do they expire, and when may they be inherited automatically? | Current architecture permits multi-source context but leaves deployment and risk profiles open. | active-context profile |
| U41 | How does Role outward intent compose with visibility, discovery, access control, rights, audience membership, and publication approval? | Intent is explicitly not enforcement, and the complete exposure workflow has not yet been extracted. | sharing/publication tranche |
| U42 | What redaction, review, update, and withdrawal rules apply when private Role knowledge is copied into an outward representation? | Source separation is required, while synchronization and correction semantics vary by representation and risk. | outward-representation profile |
| U43 | Which observed Role or Mode signals may become proposals, and what evidence threshold is required? | Persistent context definitions require confirmation, but one cross-domain proposal threshold is not established. | context-governance profile |
| U44 | What creation and surfacing thresholds apply to observed patterns by evidence class and risk? | The historical application defines numeric defaults, while current PIOS does not adopt one universal threshold. | pattern-detection profile |
| U45 | What formula and time windows govern pattern strength, weakening, inactivity, and reactivation? | Sources require temporal lifecycle evaluation but do not establish one portable calculation. | pattern-lifecycle profile |
| U46 | How are duplicate, overlapping, nested, or contradictory observed patterns identified and reconciled? | Pattern identity and similarity semantics are not fully specified. | pattern-governance profile |
| U47 | What owner actions exist for dismissing, suppressing, correcting, or marking an observed pattern as meaningful? | Sources describe user-facing patterns and planned inspection, but not one complete portable feedback lifecycle. | pattern-review profile |
| U48 | What portable relationship contract links goals, objectives, targets, plans, projects, tasks, and reviews without imposing one mandatory hierarchy? | The objects are independently meaningful and historical ordering is explicitly conceptual, while current PIOS expects connected direction and work. | direction/execution interoperability profile |
| U49 | What evidence and authority are required to declare, reverse, or dispute target achievement? | Target definition is supported, but reviewed sources do not establish one reusable achievement-evaluation lifecycle. | target-evaluation profile |
| U50 | What correction, quality, duplicate, source-precedence, and aggregation rules apply to metric observations? | The observation element is supported, while domain-specific measurement semantics vary substantially. | measurement profile |
| U52 | What recipient-identity assurance and delegation profiles are required for controlled sharing? | Email, account, password, invite and relationship-based mechanisms provide different assurance and forwarding risk. | outward-access profile |
| U53 | How should publication withdrawal propagate to caches, mirrors, search indexes, agent indexes, archives, and previously downloaded copies? | Core can revoke its own availability and signal withdrawal but cannot guarantee immediate deletion by every external system. | publication lifecycle profile |
| U54 | Which machine-readable rights vocabulary and precedence rules should PIOS adopt for human, crawler, agent, indexing, training, redistribution, attribution, and commercial-use conditions? | Historical design requires extensibility, while no single portable policy standard is adopted by the current framework. | rights interoperability profile |
| U55 | What constitutes sufficient evidence that a discoverability change has propagated or that de-indexing has succeeded? | Declared state, emitted directives, index submission, and third-party observed behavior are different evidence levels. | discovery verification profile |
| U56 | Which public-presence namespace, custom-domain, path-stability, and ownership-verification capabilities should be standardized beyond generic publication? | Historical realization patterns are detailed, but the current framework does not mandate one addressing or hosting model. | public-presence tranche |
| U57 | Which review questions, source windows, completion criteria, and owner-participation requirements apply to each review profile? | The generic review contract is supported, while daily, weekly, monthly, yearly, event-triggered, project, and domain reviews need different profiles. | review profile |
| U58 | What statement-level provenance and confidence are required when a model generates a reflection from multiple notes, messages, events, or summaries? | The reviewed realization produces prose from bounded inputs but does not preserve complete claim-level evidence links. | reflection evidence profile |
| U59 | When may a review directly update an existing object, and when must it emit a proposal or owner decision request? | Sources require governed downstream changes but do not establish one cross-domain authority matrix. | review governance profile |
| U60 | How should duplicate or partially matching person identities and contact profiles be merged without conflating different people? | Stable identity, aliases, source evidence, and owner-specific relationship knowledge may disagree across sources. | person-identity resolution profile |
| U61 | Which contact-point verification methods, assurance levels, expiry rules, and reuse conditions apply outside onboarding? | A generic verification outcome is independently meaningful, while email, phone, address, social and account contexts have different risks. | contact verification profile |
| U62 | What consent, correction, retention, and disclosure rights apply to owner-held profiles and relationship records about other people? | Current PIOS requires distinct subject authority and consent handling but does not define one universal cross-jurisdiction policy. | relationship/privacy profile |
| U63 | How should reciprocal, group, organizational, and time-varying relationships be represented across owners without asserting symmetry? | An owner's relationship interpretation may not be shared by the other party and may change independently over time. | relationship interoperability profile |
| U64 | What portable schema, signing, compatibility, and secret-reference rules apply to canonical agent definitions? | Current PIOS defines the conceptual content and governance but leaves representation and validation profiles open. | agent-definition interoperability profile |
| U65 | How are intentional runtime differences approved, expired, reconciled, and distinguished from stale or failed synchronization? | Runtime targets may legitimately need adaptations, but silent drift must not override canonical definitions. | agent synchronization profile |
| U66 | What universal runtime-role vocabulary and delegation-depth constraints should PIOS define, if any? | Historical director/manager/worker terminology is useful but may be implementation-specific. | orchestration profile |
| U67 | In which legal, professional, relational, or safety contexts is undisclosed AI representation prohibited regardless of standing owner authority? | Identity disclosure affects recipients and may create obligations beyond owner preference. | outward-identity policy |
| U68 | What minimum response provenance, participant consent, abuse handling, escalation, and retention contract applies to owner-representative conversations? | The reusable conversational outcome is clear, while public, community, family, and professional contexts have different risks. | representative-conversation profile |
| U69 | How should an outward AI representative's dedicated knowledge scope be versioned, reviewed, corrected, and withdrawn across active conversations? | Private-source separation is required, but live update and stale-answer semantics are not fully specified. | representative knowledge profile |
| U70 | How should collaboration-channel and thread identities, participants, references and lifecycle state federate across replaceable harnesses? | Current PIOS requires replaceability, while historical and restricted realizations use implementation-specific structures. | collaboration interoperability profile |
| U71 | Which thread-depth, inactivity, waiting, blocked, resolution, reopening and archival semantics should be universal rather than profile-specific? | One-level branching is historically well supported, but current PIOS does not mandate one thread state machine for every harness. | discussion-thread profile |
| U72 | What edit, deletion, redaction, authenticity, delivery-receipt and retention rules apply to collaboration messages in different risk and audience contexts? | The attributable envelope is reusable, while communication channels and legal contexts require different evidence and retention controls. | collaboration-message profile |
| U73 | Which isolation, resource, snapshot, retention, cleanup, secure-erasure and crash-recovery guarantees apply to task-scoped execution workspaces? | Runtime and data sensitivity vary, and admitted sources do not establish one universal workspace technology or assurance level. | execution-workspace profile |
| U74 | Which multi-agent loop-control fields, grant semantics, hop/turn limits, budgets and stop conditions form the minimum interoperable profile? | Current PIOS defines required categories but leaves values and cross-harness enforcement open. | multi-agent communication profile |
| U75 | What is the interoperable unit of personal conversation history: message, exchange, turn pair, source event, or another envelope? | Historical and restricted realizations pair owner input and assistant response, while the reusable attributed-message contract treats each communication independently. | conversation-history interoperability profile |
| U76 | When should one logical personal conversation history be exposed as multiple separately governed histories rather than source-aware views? | Continuity favors one history, but legal, organizational, shared-account, safety, or multi-owner contexts may require stronger separation. | conversation-history profile |
| U77 | What assurance, health-check frequency, offline guarantee, failover order and break-glass test applies to each owner access-path role? | Deployment risk and platform capabilities vary, and the historical role vocabulary does not establish one universal profile. | owner-access-path profile |
| U78 | Which cache validation, integrity, size, eviction and telemetry profiles apply by content class and device type? | The draft capability distinguishes non-canonical local-copy state, while the committed framework leaves the detailed cache profile unresolved. | device-cache profile |
| U79 | How should access revocation propagate to offline devices, and what deletion or expiry guarantees can be made for already disclosed bytes? | Disconnected devices cannot receive immediate revocation, and shared-container readers may already possess plaintext copies. | offline-access profile |
| U80 | What conflict-resolution rules apply when an offline-capable client reconnects with stale local state or pending edits? | Current PIOS prohibits silent canonical overwrite but does not define one cross-domain merge policy. | offline-reconciliation profile |
| U81 | What evidence is sufficient to mark a reading item complete: explicit action, progress threshold, dwell time, end-of-item visibility, or another signal? | Historical intent and the reviewed implementation differ, and brief visibility is weak evidence of actual reading. | reading-queue profile |
| U82 | Which reading-queue states must be durable and portable across devices, and which may remain local presentation preferences? | The reviewed realization stores some state in canonical-looking records and some only in browser-local storage. | reading-state interoperability profile |
| U83 | Which common resource units and conversion rules should PIOS support across tokens, compute, time, storage, energy, credits and money? | The historical credit concept is intentionally abstract, while implementations incur heterogeneous resources and monetary costs. | resource-unit profile |
| U84 | What estimate confidence, expiry and acceptable-error rules apply by operation class? | Rough ranges may support decisions, but high-impact actions may require stronger evidence than low-cost work. | cost-estimation profile |
| U85 | How should concurrent reservations, overcommit, extension, expiry and recovery be coordinated across distributed executors? | The historical model defines reservation intent but not a universal consistency protocol. | resource-reservation profile |
| U86 | How are late usage observations, retries, shared infrastructure allocation, corrections and disputed measurements reconciled? | Actual resource attribution can arrive after completion and may be shared across several operations. | resource-accounting profile |
| U87 | When do internal credits acquire monetary meaning and require separate billing, consumer-protection, tax, refund or payment capabilities? | The admitted source explicitly excludes billing while allowing later economic meaning. | commercial-governance boundary |
| U88 | What passive and active inspection methods are permitted for each source-discovery class, and who interprets robots, terms and legal constraints? | Candidate discovery must remain non-collecting, but source types and jurisdictions differ. | source-discovery profile |
| U89 | When should a source-discovery candidate expire, merge with another candidate, or be suppressed after rejection? | Repeated discovery can create noise or bypass a prior owner decision if lifecycle rules are absent. | source-candidate lifecycle profile |
| U90 | Which owner implementation documents are canonical records, projections, or references to external configuration? | Historical local-documentation and current Core models do not establish one universal authority map. | implementation-documentation profile |
| U91 | How should local implementation documentation synchronize across devices and reconcile with Core knowledge without exposing secrets or overwriting newer state? | The historical master-location question remains unresolved. | knowledge-environment synchronization profile |
| U92 | Which knowledge-integrity profiles, severities, schedules and coverage evidence are required for different knowledge classes? | Structural, evidence, meaning and safety defects need different checks and risk treatment. | knowledge-integrity profile |
| U93 | Which low-risk knowledge repairs may be automatically applied under standing authority, and which must remain proposals or owner review tasks? | Current PIOS favors flags and proposals but does not define a universal auto-fix boundary. | knowledge-maintenance governance profile |
| U94 | What evidence threshold and review process are required before proposed Meaning or Learning becomes owner-confirmed? | Risk and reversibility vary by subject, and the current lifecycle does not define one universal threshold. | cognitive-memory confirmation profile |
| U95 | Which confidence scales, review intervals, expiry rules, and disagreement states should Meaning and Learning use across domains? | The records require these semantics but leave their common vocabulary extensible. | cognitive-memory interoperability profile |
| U96 | How should conflicting Meaning records coexist, merge, or supersede one another without hiding context-specific interpretations? | Different contexts can support different significance, while silent merging would erase provenance. | Meaning lifecycle profile |
| U97 | How should confirmed Learning influence recall and recommendations without silently becoming ranking policy or behavior adaptation? | Recall eligibility is supported, but weighting and adaptation require separate authority. | Learning recall/adaptation profile |
| U98 | Which model, dimension, modality, format, and semantic-space changes create a new representation identity versus a compatible revision? | The architecture requires incompatible spaces to remain distinct but does not define universal equivalence rules. | derived-representation identity profile |
| U99 | What retention and deletion evidence is sufficient when a representation is rebuildable, distributed, cached, or held by an external processor? | Logical deletion, provider deletion, cache expiry, and rebuild prevention may complete at different times. | derived-representation deletion profile |
| U100 | How should source revocation propagate atomically across indexes, vectors, graph snapshots, summaries, caches, and in-flight retrieval? | Fail-closed exclusion is required, but one cross-engine consistency protocol is not established. | derived-representation revocation profile |
| U101 | What evidence and authority are required to promote a proposed source-local graph match into a canonical entity resolution? | Source-local ambiguity must be preserved, while global identity changes affect shared knowledge. | entity-resolution capability boundary |
| U102 | Which artifact classes require explicit owner approval, delegated review, or standing authority before canonical promotion? | Risk, reversibility and owner significance differ across knowledge, configuration, media, results and operational records. | artifact-promotion governance profile |
| U103 | How should promotion resolve conflicts when the target canonical object changed after the working copy was created? | Silent last-writer-wins behavior could discard newer owner state or accepted evidence. | artifact-promotion conflict profile |
| U104 | When may temporary source artifacts be removed after promotion, and what verification or rollback window is required? | Premature cleanup can destroy the only recoverable copy even when a write appeared successful. | artifact-promotion durability profile |
| U105 | Which transformations are permitted during promotion without requiring a separately reviewable derived object? | Format normalization may be harmless, while summarization or semantic rewriting can change meaning. | artifact-promotion transformation boundary |
| U106 | Which source-specific mapping profiles and ownership evidence thresholds are sufficient when composing a PIOS Portability Package without an existing Core export? | Source-composed packages must preserve raw provenance and uncertainty without implying canonical Core state. | source-composed portability profile |