1. Overview
Digital painting application with a documented project archive format.
Category: Graphics & 3D.
2. Version and scope assessed
Version assessed: Source commit b5b6dd3c8b53944f67a824f7f938f4bbfa80275d; KRA archive relationships and OpenRaster editable-state limits.
3. Overall determination
Computing determination
4. Principle profile
| Order | Principle | Finding |
|---|---|---|
| I | Sovereignty | Not assessed |
| II | Longevity | Not assessed |
| III | Locality | ✓ Meets |
| IV | Transparency and Control | Not assessed |
5. Fundamental requirements
| Requirement | Status |
|---|---|
| E1 Independent access to essential information | ✓ Pass |
| E2 Practicable exit and migration | ? Not Verified |
| E3 Independent interpretation and recovery | ? Not Verified |
| E4 Continuing authority and custody over already-created work | ✓ Pass |
| E5 Governability of consequential actions | ? Not Verified |
6. Evidence and verification
- E1: The retained KRA opened as a seven-member ZIP. Namespace-aware maindoc.xml parsing identifies a 100-by-100 RGBA image and Layer 1, whose filename layer0 maps to the archive's built image/layers/layer0 payload; ICC files and preview.png are also present. This historical fixture has no mergedimage.png. Layer pixels and color-profile semantics were not decoded or rebuilt. (source), confidence high
- E2: The OpenRaster visitor saves generator, clone and external layers through their raster projection, preserves groups as stacks, and skips fake nodes such as reference-image/grid layers. Its adjustment-layer branch creates a Krita-specific filter element but does not append it to the stack in that branch. ORA therefore cannot be assumed to preserve every native editable construct; no export/import was executed. (source), confidence medium
- E3: The native file can be inspected as a compressed archive and layers can sometimes be recovered, but independent reconstruction was not tested. (source), confidence medium
- E4: The editing workflow is local-file-based and does not require a hosted account. (source), confidence medium
- E5: Image editing is user-directed, but asset provenance, overwrite, and publishing review were not assessed. (source), confidence low
- sovereignty: A positive Sovereignty finding requires established E1, E2 and E4 in the declared scope. The existing access/exit/custody record for Krita does not establish all three minimums. The prior positive finding is withdrawn; recorded storage and portability strengths remain facts, not a verified failure. (source), confidence medium
- longevity: E3 is not established for Krita's existing essential-record scope. The previous Longevity finding is replaced by Not assessed, not a verified failure or a positive placeholder. (source), confidence medium
- locality: Core editing and storage operate locally without a provider. (source), confidence medium
- transparency: The positive control observations above do not yet establish whole-scope E5. The methodology requires that minimum before a positive Transparency and Control finding; the previous positive finding is therefore withdrawn to Not assessed, not changed to Does not meet. (source), confidence medium
- E3: The historical KRA exposes a layer/payload relationship and profiles but its pixel data/color semantics were not independently rebuilt. OpenRaster source projects or skips some native constructs, so neither equivalent layers/masks/animation nor complete native recovery follows from ZIP readability. (source), confidence medium
- E5: User-directed image editing does not establish plugin/script authority, save/export overwrite decisions or correction after layer and animation changes. Conditional backups/autosave and effective settings still lack sufficient evidence for this profile. (source), confidence medium
7. Migration and recovery
Native storage format: Project archive (.kra, a zip containing maindoc.xml and layer data).
Synchronization or runtime model: Local desktop application.
Example export or inspection command (not verified against any particular version or data set): unzip -l painting.kra
8. Architectural strengths
Established strengths and their scope are recorded in the evidence and assessment findings on this page.
9. Architectural limitations
- Archive/XML inspection establishes structure, not reconstruction of layer pixels or color appearance.
- OpenRaster uses projections for several layer types and is not established as a lossless editable-native backup.
10. Assessment findings and remaining work
Evidence update: 23 October 2026
- Resolved: The retained KRA opened as a seven-member ZIP. Namespace-aware maindoc.xml parsing identifies a 100-by-100 RGBA image and Layer 1, whose filename layer0 maps to the archive’s built image/layers/layer0 payload; ICC files and preview.png are also present. This historical fixture has no mergedimage.png. Layer pixels and color-profile semantics were not decoded or rebuilt. Source.
- Resolved: The OpenRaster visitor saves generator, clone and external layers through their raster projection, preserves groups as stacks, and skips fake nodes such as reference-image/grid layers. Its adjustment-layer branch creates a Krita-specific filter element but does not append it to the stack in that branch. ORA therefore cannot be assumed to preserve every native editable construct; no export/import was executed. Source.
- Open: Native pixel reconstruction, masks/vector/text/animation and color fidelity across ORA/PSD/PNG, actual adjustment-layer export behavior, version round trips, backup/autosave recovery and update/network controls. E5 needs save/autosave, plugin/script and destructive-edit/overwrite visibility and correction boundaries.
Assessment follow-up: These findings now appear in the application’s evidence and limitations. At the user’s request, existing eligibility and principle ratings are unchanged; E3/E5, principle consistency and blank-status fixes will be reconciled in the next pass. Reproduction details and retained inputs are in evidence/third-pass/batch-5/.
Human-readable criteria: Can a creator preserve editable source work and linked assets, reopen it after software changes, and export a useful representation to independent tools?
Rating reconciliation: 24 October 2026
E3 and E5 remain Not Verified for the existing declared scope. Longevity and Transparency and Control are Not assessed pending their required minimums. Sovereignty is also Not assessed because the required access/exit/custody minimums are not all established. This is a targeted evidence decision, not a finding that the product fails. Existing E1, E4 and Locality findings were not re-certified.
Remaining: Native pixel reconstruction, masks/vector/text/animation and color fidelity across ORA/PSD/PNG, actual adjustment-layer export behavior, version round trips, backup/autosave recovery and update/network controls. E5 needs save/autosave, plugin/script and destructive-edit/overwrite visibility and correction boundaries.
Next without installing locally: Use a synthetic KRA with representative layers/masks/text/animation and dependency/color manifest, native/interchange exports and reference comparisons; inspect archives and seek matching save/undo/autosave controls.
The individual decision and provenance are retained in evidence/rating-reconciliation/batch-6/. Overall: Insufficient evidence.
Contribute verification evidence for Krita
Have you tested clean-machine restoration, format migration, or failure rollback for Krita? We welcome reproducible laboratory logs, synthetic test fixtures, and independent assessments to resolve open findings.
Read the evaluation protocol · Submit verification records on GitHub
Individually reconciled in rating batch 6 on 24 October 2026. E3/E5 remain Not Verified for explicit missing coverage; dependent unsupported findings corrected. Previously resolved questions are retained, not counted again. E1/E4/Locality were not re-certified by this targeted review. The assessment procedure is described in the methodology.