Integrity-first execution
What must remain true before software continues execution, and how should an integrity concern be represented?
ArcScript research.
An experimental programming-language and resilience-architecture programme within Fallon Apus Orbital Systems. The research question: how should software represent abnormal conditions, recovery decisions and the evidence needed to review them?
ArcScript — Resilience Architecture Research
ArcScript is Fallon Apus Orbital Systems’ experimental programming-language and resilience-architecture research programme.
It explores integrity-first execution, explicit anomaly handling, operational state, recovery concepts and auditable mission evidence for demanding engineering environments.
Status: research and specification. ArcScript is proprietary Fallon Apus intellectual property. It is not flight-proven, independently validated, certified or operationally deployed.
From an anomaly to a reviewable decision.
The programme explores five connected questions. These describe research intent, not implemented or verified language features.
Explicit anomaly handling
How should an abnormal condition be distinguished from ordinary execution, rather than hidden inside an unexplained error?
Operational state
What state was the system in when the anomaly occurred, and which transitions should be considered?
Recovery concepts
Under what assumptions would a recovery action be appropriate, and when should further action be withheld?
Auditable evidence
What record would let an engineer review the condition, decision, outcome and unresolved uncertainty?
A remote system loses communication.
Consider a hypothetical remote system that cannot receive its next instruction. An ArcScript research discussion would ask how to represent that condition, what operational state is relevant, which recovery assumptions are valid and what information should be retained for later review.
- 01Condition
- 02Operational state
- 03Assumptions
- 04Recovery decision
- 05Observation
- 06Review
This is a proposed discussion scenario, not a demonstration of ArcScript behaviour or evidence of mission readiness.
A satellite sensor drifts out of bounds.
A hypothetical satellite scenario connects ArcScript’s research questions: identify the anomaly, examine operational state and integrity, state recovery assumptions, and retain a reviewable record. The animation illustrates proposed reasoning, not a working ArcScript implementation.
Scenario transcript
Concise text equivalent of the on-screen scenario.
- 0:00
Satellite scenario. How might ArcScript reason about a satellite anomaly? This is a hypothetical research scenario, not flight-proven software, real telemetry or verified behaviour.
- 0:03
Operational state. Know the state before the fault. The discussion starts with a defined operating state and illustrative telemetry.
- 0:06
Anomaly. Name the anomaly. A sensor drifts out of bounds. Treat it as a named condition, not an unexplained error.
- 0:09
Integrity check. Check integrity before continuing. Explore whether the observation is consistent, the relevant assumptions still hold, and execution should be withheld.
- 0:12
Recovery assumptions. State the assumptions. Know when to stop. Consider power, communications and ground-contact assumptions before proposing a bounded safe-hold response.
- 0:15
Reviewable evidence. Leave a record an engineer can review: the condition, operational state, decision, assumptions and unresolved uncertainty.
- 0:18
Research status. ArcScript: resilience-architecture research and specification. A hypothetical illustration, not evidence of implemented capabilities, tested recovery or mission readiness.
Specification is not verification.
ArcScript is at research and specification stage. This page does not establish an available compiler, runtime, downloadable product, tested recovery mechanism or measured performance.
Evidence for any future claim would need a defined requirement, a described implementation and configuration, repeatable test conditions, observed outcomes and explicit limitations. Until that evidence is available, these remain research questions.
Discuss an ArcScript anomaly or recovery questionEngineering Evidence & Assurance
Engineering programmes generate requirements, assumptions, risks, implementation changes, tests and evidence across complex toolchains.
Fallon Apus is investigating software architectures that connect these artefacts and make their relationships easier to trace, review and maintain.
- 01Requirement
- 02Risk / Assumption
- 03Implementation
- 04Test
- 05Result
- 06Evidence
- 07Approval
A particular area of investigation is change-impact analysis: understanding which requirements, tests and evidence may require review when an engineering system changes.
Status: conceptual research. This is not a finished product.
Space & Orbital Systems
Space remains a strategic application domain for Fallon Apus Orbital Systems. Long-duration and remote systems present demanding engineering problems involving autonomy, resilience, verification, communications constraints and evidence.
Our long-term research investigates how software architecture can contribute to these environments.
Fallon Apus has no endorsement, partnership, procurement or funding relationship with any space agency or institution.
Separate the idea from the evidence.
Our programme descriptions state what we are investigating; they are not proof of performance or readiness for a mission. Any future demonstration needs its assumptions, configuration, observed results and limitations to be reviewed together.
Space research questions & evidence approachWORK WITH FALLON APUSWorking on a difficult
Working on a difficult
engineering problem?
We are interested in conversations with engineering organisations working on autonomy, assurance, resilience and complex software systems.
Discuss an Engineering Problem