01
Evidence
Data provenance. Where did the data come from? Which assumptions support the conclusion?
R&D / 2026
UKRAINE
UKRAINE
DECISION ASSURANCE / INDEPENDENT R&D
ASSURANCE BEFORE ACTION.
Architecture review for critical software.For technology teams and integrators. Identify trust boundaries and evidence gaps before an integration decision.
Review deliverables
- Trust-boundary map
- Evidence-gap register
- Conclusion within the agreed scope
For systems where the right to act must have a defensible basis.
Scroll to explore01 / THE PRINCIPLE
Analysis proposes. Authority sets the boundaries.
A conclusion, permission and an outcome serve different roles. My focus is to make their relationship explicit, controlled and open to verification.
VISUAL CONTEXTField workspace
02
Authority
Scope of authority. Who may authorize an action, within what scope and under which conditions?
03
Outcome
Confirmed outcome. What has actually been confirmed after execution was attempted?
DECISION ASSURANCE / EXPLAINED
An engineering approach to defensible decisions.
aviassurance brings together six authored research and engineering programmes. Their shared task is to connect evidence, authority, system state and outcome confirmation. Each programme addresses a distinct part of this task.
02 / RESEARCH DOMAINS
Complex environments. Explicit trust boundaries.
Defence and civilian critical systems share an engineering challenge: retaining control where errors carry consequences.
VISUAL CONTEXTOptical equipment in a field setting
ANALYSIS ≠ AUTHORITY
PROVENANCE → ASSESSMENT
Intelligence & analysis
Data provenance, defensible analytical conclusions and separation of assessment from the authority to act.
Explore the architecture03 / THE ARCHITECTURAL APPROACH
From information to accountable action.
The architecture separates the basis for a conclusion, authority to execute and confirmation of an outcome. Each responsibility has its own inputs, criteria and limits.
VISUAL CONTEXTModular architecture
Three responsibilities. No implicit handoff.
Evidence supports a conclusion. Authority bounds an action. Confirmation records what actually happened.
RESPONSIBILITY MAPDA / 01—03
Select a responsibility to explore its requirements
What is known?
Information has a source, context and defined confidence boundaries. Assessment concerns a specific claim and the conditions under which it is checked.
Output: a reasoned assessmentWhat enters
A claim, its sources, acquisition time and observation conditions.
What is recorded
An assessment linked to its basis, checking conditions and explicit uncertainties.
What is checked
- Provenance and integrity of the material.
- Freshness, context and admissibility for this claim.
- Contradictions, gaps and confidence boundaries.
Boundary of the conclusion
A defensible assessment does not, by itself, grant authority.
What enters
A reasoned request, an identified authority and the permitted scope of the operation.
What is recorded
A separate admission or refusal decision, with its basis and scope.
What is checked
- Who granted authority and to whom.
- The specific operation, object and limits it covers.
- Whether authority remains valid and when execution must stop.
Boundary of the conclusion
Admission concerns a defined operation. It does not confirm that the operation happened.
What enters
The admission decision, a record of the attempt and available observations of the outcome.
What is recorded
An operation trail separating permission, attempt, confirmed outcome and what remains unknown.
What is checked
- What was permitted and what was actually attempted.
- Who or what confirms the outcome, and within which limits.
- Whether records agree and any consequences remain unconfirmed.
Boundary of the conclusion
A software receipt does not prove a physical effect without the relevant external observation.
Explore the requirements for your systemSelect a responsibility, examine its boundaries and prepare questions for discussion.+
WORKING REVIEW / RESPONSIBILITY MAP
From architecture to specific questions.
The diagram explains relationships between three responsibilities. Add your own notes to an inquiry. Assessing a system requires its evidence and a separate review.
01 / SELECTED STAGE
A sufficient basis for a specific claim.
Identify the claim, source, material version and observation conditions. Record contradictions and what still needs checking.
Check provenance before assessing admission.Boundary of the conclusion
A defensible assessment does not, by itself, grant authority.
Your architecture questions
Notes stay on this page. Add them to an inquiry to edit them and optionally save a draft. Do not include secrets.
Responsibilities with notes: 0 / 3
The link restores the selected responsibility and scale in 2D. It does not include your notes.
ARCHITECTURAL BOUNDARIES
Visible uncertainty is part of control.
- 01
Separate authority
An analytical component cannot grant execution authority through its conclusion. Admission needs its own basis and a defined scope.
- 02
Withhold when a basis is missing
If a required condition is not established, permission is withheld. The reason remains available for review.
- 03
Independent confirmation
A sent command, a software receipt and a physical effect are distinct observations. A record should identify which one is confirmed.
What this model explains — and what needs separate verification
This is a public conceptual model of responsibilities. Implementation, cryptographic mechanisms, timing constraints, recovery after failures and external equipment behavior require separate assessment for a particular system and environment.
03 → 04 / FROM ARCHITECTURE TO PROGRAMMES
Autonomy. Within defined boundaries.
The architectural boundaries define concrete research questions: local execution, evidence, controlled admission and trust across nodes. Next are the programmes that explore them.
Explore the programmesCould this apply to your system?Let’s discuss
VISUAL CONTEXTAutonomy in context
04 / RESEARCH PROGRAMMES
Different challenges. A shared discipline.
Six authored programmes with distinct research questions. Their shared focus is trust in decisions, state consistency and controlled execution.
VISUAL CONTEXTLocal computing
Only a bounded summary of the local BOARD-EX-001 check is public; programme materials are reviewed within an agreed scope. This does not qualify a release. No separate packages for the other five programmes are published here. DA-EX-001 concerns only the inquiry form on this site.
No programmes match these conditions.
PROGRAMME INDEXProgrammes shown: 06 / 06
01AVRIALExecution assuranceEXECUTION ASSURANCE
A local execution architecture for critical operations within explicitly defined authority.
RESEARCH FOCUS
- Separation of decisions and authority to act
- Controlled execution and recovery
- Traceable records of critical operations
R&D programme
02BOARDEvidence for admissionINDEPENDENT ASSURANCE
An independent evidence assessment layer for software artifacts before an admission decision.
RESEARCH FOCUS
- Claims tied to a specific artifact
- Acceptance criteria and verification boundaries
- Materials for independent technical review
R&D programme
03LIDIYALocal evidence governanceLOCAL EVIDENCE GOVERNANCE
A self-contained deterministic system for handling evidence and its acceptance rules.
RESEARCH FOCUS
- A deterministic local core without AI models
- Consistent checks and admissibility rules
- Preserving the link between conclusions and their basis
R&D programme
04ENEYControlled admissionTRUSTED ADMISSION / R&D
Staged development of a local system for trusted admission and state consistency.
RESEARCH FOCUS
- Explicit separation of proposals and authority
- Consistency of knowledge and persisted state
- Staged qualification of development candidates
R&D programme
05TCRFTrust across nodesDISTRIBUTED TRUST / R&D
Research into trust boundaries and accountable interaction between local and distributed software nodes.
RESEARCH FOCUS
- Separating received information from authority
- Traceability of interactions across nodes
- Boundaries between software receipts and external effects
R&D programme
06NEMESISJAMFormal foundationsFORMAL RESEARCH
An authored research programme on authority, evidence and the boundaries of autonomous action.
RESEARCH FOCUS
- Formulating properties and assumptions
- Discipline in technical claims
- Arguments suitable for independent review
R&D programme
05 / EVIDENCE DISCIPLINE
A claim must stand up to scrutiny.
The open DA-EX-001 case demonstrates the method on the inquiry form of this site. For research programmes, the public site presents purpose, bounded summaries and conclusion limits; technical materials are reviewed within an agreed scope.
Explore evidence discipline
VISUAL CONTEXTData review
DA-EX-001 / PUBLIC CASE
One mechanism. An inspectable check.
Replaying a valid inquiry with the same requestId and normalized content returns the original receipt while its stored record remains unchanged. The 12 October 2026 package contains the historical form handler, specification, verifier and recorded report; the current API has additional safeguards.
- 01Claim
- One record per key
- 02Artifact
- This site’s form handler
- 03Property
- Replay returns the receipt
- 04Verification
- 347 control requests
- 05Boundaries
- Local Node.js + SQLite
This demonstrates the method using an inquiry form. It does not establish the properties or readiness of the six research programmes.
F-1 / F-2: coverage correction and additional checks ↗
Re-executed by the same executor; independent external verification has not been performed. Reproduction record and limitations ↗
06 / ABOUT
Independent researcher & systems developer
Andriy
Ivanov.
Ukraine · international collaboration
VISUAL CONTEXTTechnical workspace
Engineering accountability.
Working at the intersection of systems architecture, formal methods and cryptographic accountability. I investigate how critical systems can justify decisions, constrain execution and maintain a verifiable trail.
My focus is on local architectures, separation of analysis from authority and materials for independent technical assessment.
Contact the researcher directly
1westwestwest@gmail.comPROFESSIONAL PROFILE
Research directions and opportunities for collaboration, at a glance.
07 / TECHNICAL COLLABORATION
Start with your challenge.
For technology teams, research institutions, integrators and technical customers.
- Joint research
- Architecture review
- Integration assessment
Contact the researcher directly
1westwestwest@gmail.com
VISUAL CONTEXTA space for shared planning