@tiinex/app 0.1.1

package/src/schemas/core/evidence/tiinex.evidence.v1.schema.md

@@ -0,0 +1,318 @@
+# Continuity Context
+
+- Envelope Schema: [tiinex.root.v1](../../tiinex.root.v1.schema.md)
+- Parent
+  - Parent Schema: [tiinex.preservation.v1](../preservation/tiinex.preservation.v1.schema.md)
+  - Created At: 2026-06-30 00:00:00
+  - Trace: [tiinex.preservation.v1.schema.md](../preservation/tiinex.preservation.v1.schema.md)
+  - Origin:
+    - [relative](../preservation/tiinex.preservation.v1.schema.md)
+    - [browse + git](https://github.com/Tiinex/docs/blob/089427470f04336dfcc100c4dcf6289d51bf0291/.topics/.schemas/core/preservation/tiinex.preservation.v1.schema.md)
+- Current
+  - Current Schema: [tiinex.evidence.v1](tiinex.evidence.v1.schema.md)
+  - Created At: 2026-06-30 00:00:00
+  - Summary: Schema for preserved material used to support, illuminate, test, or challenge a claim or question, inheriting preservation boundaries.
+
+---
+
+# Evidence
+
+- Status: maintained schema note
+
+## Summary
+
+This schema defines evidence artifacts as a preservation specialization.
+
+Evidence is preserved material used to support, illuminate, test, or challenge a claim, question, decision input, review, or interpretation. It inherits the preservation rule that material must remain judgeable with provenance, fidelity, representation, and loss boundaries visible.
+
+Evidence is not all preservation. Preserved material can exist before it is used as evidence. Evidence begins when preserved material is placed in relation to a supported claim, question, or issue while keeping interpretation limits visible.
+
+## Schema Validation Contract
+
+### Evidence Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.evidence.v1`
+
+Rules
+
+- `tiinex.evidence.v1` identifies artifacts centered on preserved supporting material used for a claim, question, review, or interpretation.
+- Evidence artifacts inherit `tiinex.preservation.v1` semantics for preserved material, provenance, fidelity, custody or storage boundary, and interpretation limits.
+- An evidence artifact should let a later reader tell what material is preserved, what it supports or bears on, how it represents the underlying source, and what it does not prove.
+- Evidence artifacts must not silently become truth, attestation, validation, consent, decision, relation, or authority artifacts.
+- Prose outside `Schema Validation Contract` may explain the schema, but it does not add required validation rules.
+
+### Parent Preservation Specialization
+
+Rules
+
+- Evidence narrows preservation by adding a supported claim, question, or issue.
+- Evidence uses preserved material; it does not create preservation merely by linking, seeing, fetching, or temporarily holding material.
+- Evidence body sections replace the generic preservation body for artifacts whose current schema is `tiinex.evidence.v1`.
+- Parent preservation specialization applies to the artifact body only; it does not alter root continuity, integrity, or parent-origin requirements.
+
+Inheritance Overrides
+
+- evidence-preservation-body-structure
+  - Merge Operation: override
+  - Parent Schema: tiinex.preservation.v1
+  - Parent Node: Schema Validation Contract / Preservation Body / Required Shape
+  - Child Node: Schema Validation Contract / Evidence Body / Required Shape
+  - Reason: Evidence specializes Preservation by replacing only the generic Preservation artifact-body structure while retaining compatible non-structural Preservation semantics and provenance.
+  - Effective Result: Evidence body structure is authoritative for Evidence artifacts; parent-only structural body groups become inactive, while compatible parent contributions targeting surviving Evidence sections remain active.
+
+### Evidence Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- `## Supported Claim Or Question` section
+- `## Provenance` section
+- `## Evidence Material` section
+- `## Preservation And Fidelity` section
+- `## Interpretation Limits` section
+
+Optional Sections
+
+- Representation
+- Linked Preservation Artifact
+- Linked Artifacts
+- References
+- Fidelity Notes
+- Dispute Or Counter-Evidence
+- Review Notes
+
+Rules
+
+- An evidence artifact should begin with a human-readable title.
+- `Supported Claim Or Question` must expose the claim, question, issue, or review point the evidence bears on.
+- `Provenance` must expose what is known about source, origin, preservation, and representation.
+- `Evidence Material` must expose the preserved supporting material itself or a bounded reference to a preservation or external payload artifact.
+- `Preservation And Fidelity` must state preservation method, fidelity, loss, transformation, redaction, or excerpting limits when known.
+- `Interpretation Limits` must state what the evidence does not prove.
+- Follow-up sections must not replace the preserved material or preservation boundary.
+
+### Supported Claim Or Question
+
+Required Fields
+
+- Supported Claim Or Question
+- Evidence Role
+
+Optional Fields
+
+- Claim Reference
+- Target Artifact
+- Review Context
+- Counterclaim
+- Decision Context
+
+Rules
+
+- `Supported Claim Or Question` should be readable rather than hidden in metadata.
+- `Evidence Role` should state whether the material supports, illustrates, challenges, weakens, contextualizes, or tests the claim or question.
+- Evidence does not make the supported claim true by itself.
+
+### Provenance
+
+Required Fields
+
+- Known Source
+- Preservation Basis
+- Provenance Limits
+
+Optional Fields
+
+- Origin
+- Source Artifact
+- Access Artifact
+- Preservation Artifact
+- Relation Artifact
+- Capture Time
+- Custody Context
+
+Rules
+
+- `Known Source` should name the source or bounded source descriptor when known.
+- `Preservation Basis` should state whether material is embedded, attached, linked to a preservation artifact, referenced through an external payload, or otherwise preserved.
+- `Provenance Limits` must state missing, partial, transformed, redacted, private, or uncertain provenance when present.
+- When concrete files, traces, or other durable artifacts ground the evidence, explicit readable target references should be preferred over vague mentions.
+
+### Evidence Material
+
+Required Fields
+
+- Material
+- Material Kind
+
+Optional Fields
+
+- Excerpt
+- Description
+- Attachment Reference
+- External Payload
+- Preservation Artifact
+- Transcript Extract
+- Screenshot Description
+- Sample Reference
+
+Rules
+
+- `Material` must preserve the readable excerpt, summary, description, bundle items, transcript material, explicit asset reference, or preservation artifact reference itself rather than only naming it.
+- `Material Kind` should state whether the material is quote, excerpt, scan, photo, transcript, sample, export, attachment, snapshot, external payload, or another precise shape.
+- If the material is too large, binary, private, or machine-shaped to embed, the artifact should use a bounded preservation or external payload reference.
+
+### Preservation And Fidelity
+
+Required Fields
+
+- Preservation State
+- Fidelity Notes
+- Known Losses
+
+Optional Fields
+
+- Transformation
+- Redaction
+- Excerpting
+- Representation Limits
+- Storage Boundary
+- Custody Boundary
+
+Rules
+
+- Evidence material must be preserved or explicitly reference a preservation boundary.
+- `Preservation State` should distinguish embedded material, preserved attachment, preservation artifact, external payload, custody record, transcript, snapshot, or other bounded preservation state.
+- `Fidelity Notes` should state how directly the material represents the underlying source.
+- `Known Losses` should state what may have been lost, transformed, redacted, cropped, excerpted, normalized, summarized, or made uncertain.
+
+### Interpretation Limits
+
+Required Fields
+
+- Does Not Prove
+- Must Not Be Treated As
+
+Optional Fields
+
+- Uncertainty
+- Counter-Evidence
+- Need For Review
+- Consent Limits
+- Authority Limits
+
+Rules
+
+- `Does Not Prove` must state important claims the evidence does not support by itself.
+- `Must Not Be Treated As` should call out adjacent semantics such as truth, consent, attestation, validation, decision, permission, identity, or authority when those risks are present.
+- Evidence artifacts may support decisions, findings, feedback, tasks, reports, or attestations, but those schemas own their own role.
+
+### File Naming
+
+Allowed Shapes
+
+- `<lineage>.trace.md`
+- `<lineage>-evidence.trace.md`
+- `<lineage>-<evidence-slug>.trace.md`
+
+Rules
+
+- Evidence artifacts should keep the lineage label first.
+- The optional slug should describe the preserved material or evidence slice.
+- Evidence artifacts should prefer short human-readable slugs.
+- Evidence artifacts should keep the `.trace.md` suffix stable.
+
+### Interpretation Boundaries
+
+Rules
+
+- Use `tiinex.evidence.v1` when the artifact is mainly preserved material bearing on a claim, question, or review point.
+- Use `tiinex.preservation.v1` when the main artifact value is preservation without claim-bearing evidence use.
+- Do not use `tiinex.evidence.v1` for broad topic discussion, generic task planning, thin pointers, opaque runtime exports, or validation findings.
+- If the artifact's main job is to land what now governs, another schema should own it.
+
+## Artifact Creation Contract
+
+### Creation Fields
+
+Required Fields
+
+- Supported Claim Or Question
+- Evidence Role
+- Known Source
+- Preservation Basis
+- Provenance Limits
+- Material
+- Material Kind
+- Preservation State
+- Fidelity Notes
+- Known Losses
+- Does Not Prove
+- Must Not Be Treated As
+
+### Creation Rules
+
+Rules
+
+- Creation tools should not create evidence from material that is only linked, seen, fetched, cached, or temporarily held unless a preservation boundary is also declared.
+- Creation tools should prefer preservation artifacts when material is being captured before claim-bearing use is known.
+- Creation tools should keep evidence weaker than truth, attestation, validation, consent, identity, and authority unless separate artifacts support those claims.
+## Minimal Example
+
+```md
+# Preserved Comment Evidence Slice
+
+## Supported Claim Or Question
+
+- Supported Claim Or Question: whether external feedback mentioned mobile overflow
+- Evidence Role: supports that the issue was observed in external feedback
+
+## Provenance
+
+- Known Source: public project feedback comment
+- Preservation Basis: preserved excerpt in this artifact
+- Provenance Limits: surrounding discussion may contain additional context
+
+## Evidence Material
+
+- Material Kind: excerpt
+- Material: user reported that mobile Use-as options overflowed outside the screen
+
+## Preservation And Fidelity
+
+- Preservation State: readable excerpt preserved in markdown
+- Fidelity Notes: summarized from observed feedback text
+- Known Losses: exact UI state and device context not fully preserved
+
+## Interpretation Limits
+
+- Does Not Prove: cause of overflow, fix correctness, or user acceptance
+- Must Not Be Treated As: validation result, task completion, or consent
+```
+
+## Validation-Friendly Shape
+
+Keep this schema note in the exact section order already used here: `Summary`, `Schema Validation Contract`, `Artifact Creation Contract`, `Minimal Example`, `Validation-Friendly Shape`, and `Interpretation Notes`.
+
+Maintain the section headings exactly in this schema note. Free markdown inside those sections is allowed, but adding undeclared new section headings should be treated as schema drift.
+
+The body headings required for artifacts using this schema are: `## Supported Claim Or Question`, `## Provenance`, `## Evidence Material`, `## Preservation And Fidelity`, `## Interpretation Limits`.
+
+## Interpretation Notes
+
+- evidence is preservation with claim-bearing use
+- preserved material is not automatically evidence until an evidence artifact owns the claim or question relationship
+- evidence remains bounded by provenance, preservation, fidelity, and interpretation limits
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v1
+  - Towards: [tiinex.preservation.v1.schema.md](https://github.com/Tiinex/docs/blob/089427470f04336dfcc100c4dcf6289d51bf0291/.topics/.schemas/core/preservation/tiinex.preservation.v1.schema.md)
+  - Value: RbWNCNrr75j7UhGmcKFd-a6qJEGntHGR2EztvQXQGTQ
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: jUD3kCR-P8TIKnMDAm7rov1a6IPoyRHeGCGEC2zBO9k

package/src/schemas/core/feedback/tiinex.feedback.v1.schema.md

@@ -0,0 +1,243 @@
+# Continuity Context
+
+- Envelope Schema: [tiinex.root.v1](../../tiinex.root.v1.schema.md)
+- Parent
+  - Parent Schema: [tiinex.signal.v1](../signal/tiinex.signal.v1.schema.md)
+  - Created At: 2026-06-14 00:00:00
+  - Trace: [tiinex.signal.v1.schema.md](../signal/tiinex.signal.v1.schema.md)
+  - Origin:
+    - [relative](../signal/tiinex.signal.v1.schema.md)
+    - [browse + git](https://github.com/Tiinex/docs/blob/00adbcc5b0319410cf16752a54dcbf4813173040/.topics/.schemas/tiinex.root.v1.schema.md)
+- Current
+  - Current Schema: [tiinex.feedback.v1](tiinex.feedback.v1.schema.md)
+  - Created At: 2026-06-14 00:00:00
+  - Summary: Schema for directed feedback artifacts with target, received feedback, disposition, and limits.
+
+---
+
+# Feedback
+
+- Status: maintained schema note
+
+## Summary
+
+This schema narrows signal into directed feedback: a response from a person,
+system, reviewer, community, runtime, or other source that addresses a target
+artifact, claim, proposal, work product, or behavior and may require
+disposition.
+
+It is for feedback that should remain traceable as feedback, not merely as a
+weak signal or preserved evidence.
+
+## Schema Validation Contract
+
+### Feedback Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.feedback.v1`
+
+Rules
+
+- `tiinex.feedback.v1` identifies artifacts centered on directed feedback.
+- A feedback artifact should state the feedback target.
+- A feedback artifact should preserve or summarize the received feedback.
+- A feedback artifact should expose disposition, response, or follow-up status when known.
+- Feedback may be human-authored, machine-generated, reviewer-provided, community-provided, or system-provided.
+- Prose outside `Schema Validation Contract` may explain the schema, but it does not add required validation rules.
+
+### Feedback Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- `## Feedback Target` section
+- `## Feedback Received` section
+- `## Disposition` section
+- `## Limits` section
+
+Optional Sections
+
+- Source
+- Evidence Material
+- Response
+- Follow-Up
+- Linked Artifacts
+- Next Artifacts
+
+Rules
+
+- A feedback artifact should begin with a human-readable title.
+- `Feedback Target` should identify the artifact, claim, proposal, work product, runtime behavior, or lineage surface being responded to.
+- `Feedback Received` should preserve the feedback itself or a bounded summary with fidelity limits.
+- `Disposition` should state whether the feedback is accepted, rejected, deferred, unclear, already addressed, or pending.
+- `Limits` should state scope, fidelity, uncertainty, or reasons not to overread the feedback.
+- If the feedback source is known, the artifact should expose it through `Source`, `Feedback Received`, or provenance text.
+- Feedback artifacts should distinguish between what the source said and what the artifact author infers.
+- If the artifact mainly preserves raw supporting material for a claim without disposition, an evidence schema may be better.
+- If the artifact mainly records a landed governing outcome, a decision schema may be better.
+
+### Feedback Semantics
+
+Allowed Shapes
+
+- reviewer feedback
+- maintainer feedback
+- community response
+- user feedback
+- runtime or validator feedback
+- correction request
+- acceptance or rejection response
+- actionable critique
+
+Rules
+
+- A feedback artifact should make clear whether feedback is actionable, informational, ambiguous, or out of scope.
+- A feedback artifact should not silently convert feedback into a decision.
+- A feedback artifact may point to a later task, decision, reduction, or evidence artifact when follow-up is needed.
+- When feedback is transformed, summarized, translated, or excerpted, the artifact should expose the fidelity limit.
+- When feedback includes security, privacy, or trust implications, the artifact should not bury that signal in generic prose.
+
+### Feedback Envelope Companions
+
+Optional Fields
+
+- `Current -> Why`
+- `Current -> Summary`
+- `Current -> Authors`
+- `Current -> Origin`
+- parent signal when the feedback continues, responds to, or refines an earlier local artifact
+
+Rules
+
+- Feedback artifacts may carry light current-side metadata when it helps a reader orient quickly.
+- Parent signal should be used when feedback continues or refines a local feedback thread.
+- Envelope metadata should support, not replace, body-level target, received feedback, and disposition.
+
+### File Naming
+
+Allowed Shapes
+
+- `<lineage>.trace.md`
+- `<lineage>-<feedback-slug>.trace.md`
+
+Rules
+
+- Feedback artifacts should keep the lineage label first.
+- The optional slug should describe the feedback source, target, or response.
+- Feedback artifacts should prefer short human-readable slugs.
+- Feedback artifacts should keep the `.trace.md` suffix stable.
+
+### Interpretation Boundaries
+
+Rules
+
+- Use `tiinex.feedback.v1` when the artifact is mainly preserving directed feedback and its disposition.
+- Do not use `tiinex.feedback.v1` for weak observations that do not respond to a target.
+- Do not use `tiinex.feedback.v1` as a generic evidence bundle.
+- Do not use `tiinex.feedback.v1` for a final decision unless the artifact also lands what now governs; in that case a decision artifact may be needed.
+
+## Minimal Example
+
+```md
+# Continuity Context
+
+- Envelope Schema: tiinex.root.v1
+- Current
+  - Current Schema: tiinex.feedback.v1
+  - Created At: 2026-06-14 00:00:00
+  - Summary: Feedback on an observable reduction proposal.
+
+---
+
+# Observable Reduction Feedback
+
+## Feedback Target
+
+- Target: 001-1-1 observable reduction proposal
+
+## Feedback Received
+
+- Reviewer said the minimum visible reduction summary is useful, but should not require adopting the full Tiinex format.
+
+## Disposition
+
+- State: accepted
+- Follow-Up: keep minimum surface non-invasive
+
+## Limits
+
+- Feedback is summarized rather than quoted in full.
+```
+
+## Validation-Friendly Shape
+
+Keep this maintained schema note in the exact section order already used here:
+`Summary`, `Schema Validation Contract`, `Minimal Example`,
+`Validation-Friendly Shape`, `Interpretation Notes`, and
+`Artifact Creation Contract`.
+
+Maintain the section headings exactly in this schema note. Free markdown inside
+those sections is allowed, but adding undeclared new section headings should be
+treated as schema drift.
+
+## Interpretation Notes
+
+- feedback is stronger than a signal because it responds to a target and may require disposition
+- feedback is not automatically a decision, although it may lead to one
+- feedback artifacts should preserve what was received and how it is being handled
+
+## Artifact Creation Contract
+
+### Prompt Fields
+
+Required Fields
+
+- version
+- createTitle
+- summaryPrompt
+- summaryPlaceholder
+
+Optional Fields
+
+- whyPrompt
+- whyPlaceholder
+
+Rules
+
+- The current feedback create surface uses version `1`.
+- `createTitle` should label the create action as `Create Feedback`.
+- `summaryPrompt` should ask for the feedback title.
+- `summaryPlaceholder` should guide the user toward the feedback target or source.
+- `whyPrompt` and `whyPlaceholder` may be omitted when create flow does not ask for a why field.
+
+### Template Body
+
+Required Shape
+
+- first heading uses `# {{summary}}`
+- `## Feedback Target` section
+- `## Feedback Received` section
+- `## Disposition` section
+- `## Limits` section
+
+Rules
+
+- Generated feedback artifacts should begin with the feedback title as the first body heading.
+- `Feedback Target` should identify what the feedback responds to.
+- `Feedback Received` should preserve or summarize the feedback.
+- `Disposition` should state how the feedback is being handled.
+- `Limits` should state fidelity or interpretation limits.
+- Tools should preserve the same generated body shape even when they use a maintained built-in template.
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v1
+  - Towards: [tiinex.signal.v1.schema.md](https://github.com/Tiinex/docs/blob/00adbcc5b0319410cf16752a54dcbf4813173040/.topics/.schemas/tiinex.root.v1.schema.md)
+  - Value: BFWYft1v0Ue0gUoO236DGScvnixS7_MIEwO6mhJhkNw
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: IPQ0I6h0ehoWCg21tYSzrxAimyP0dI3PwxvaRYR5-Qw

package/src/schemas/core/interpretation/.transitions/evidence-to-interpretation-transition-definition.trace.md

@@ -0,0 +1,102 @@
+# Continuity Context
+
+- Envelope Schema: tiinex.root.v1
+- Current
+  - Current Schema: tiinex.transition.definition.v1
+  - Created At: 2026-08-19 00:00:00
+  - Summary: Canonical browser-local Evidence to Interpretation Use-as transition.
+
+---
+
+# Evidence to Interpretation
+
+## Transition Identity
+
+- Name: Evidence to Interpretation
+- Version: 1
+- Canonical Identifier: tiinex.site.evidence-to-interpretation.v1
+- Human Label: Use as
+
+## Purpose And Scope
+
+- Purpose: Create one browser-local Interpretation that explicitly uses the selected Evidence as a bounded interpretation source.
+- Semantic Boundary: Durable Use-as interpretation only; the selected Evidence remains unchanged and the result does not prove that the interpreted role is true.
+
+## Input Roles
+
+- source-evidence
+  - Meaning: Existing Evidence used as the bounded interpretation source.
+  - Minimum Count: 1
+  - Maximum Count: 1
+  - Target Kind: artifact
+  - Schema Constraint: tiinex.evidence.v1
+  - Acquisition Policy: existing-only
+
+## Output Roles
+
+- interpretation
+  - Meaning: Interpretation created by the invocation.
+  - Minimum Count: 1
+  - Maximum Count: 1
+  - Target Kind: artifact
+  - Schema Constraint: tiinex.interpretation.v1
+  - Generation Binding: target-schema
+
+## Lifecycle And Continuity Effects
+
+### Lifecycle Effects
+
+- create-interpretation
+  - Target Binding: interpretation
+  - Effect: create-new
+  - Logical Continuity: new-subject
+  - Required Materialization Operation: create
+
+### Parent Effects
+
+- interpretation-continues-source
+  - Output Binding: interpretation
+  - Parent Binding: source-evidence
+  - Effect: set
+
+## Relation Effects
+
+- none
+
+## Applicability And Conditions
+
+- Applicability Meaning: A currently selected canonical Evidence artifact may create one local Interpretation when exact schema, binding, Parent, generation, and placement authority qualify.
+- Failure Meaning: Use-as remains unavailable when the current participant is not qualified Evidence or when canonical generation/materialization authority cannot be resolved.
+- Unknown Meaning: Unknown or unavailable authority remains unresolved and must not be guessed.
+
+## Authoring Bindings
+
+- none
+
+## Placement Intent
+
+### Destination Bindings
+
+- workspace-draft
+  - Meaning: Browser-local workspace selected by this invocation.
+  - Required: yes
+
+### Output Placements
+
+- interpretation-placement
+  - Output Binding: interpretation
+  - Destination Binding: workspace-draft
+  - Placement Intent: new-materialization
+  - Naming Authority: explicit-binding
+  - Explicit Override Allowed: no
+
+## Interpretation Limits
+
+- Does Not Prove: that the selected target role is correct, complete, accepted, authorized, or remotely published.
+- Must Not Be Inferred: source mutation, universal Use-as applicability, source provenance for the created local artifact, or generic Reference semantics.
+
+# Continuity Integrity
+
+- bundled-source-identity-v1
+  - Towards: self
+  - Value: tiinex.site.bundle:evidence-to-interpretation-transition-definition.trace.md:v1