What we observed
A service response, a file or a test result describes a particular situation. We keep its context and date so the result can be checked without presenting it as permanent.
Engineering
Results you can trace.
We start with a concrete problem and keep the connection between observations, changes and results. These distinctions explain the stages of our projects.
How we describe progress
What we built
Code and a prototype can exist before a product is public. Each project page says whether there is something to try, download or simply explore.
What we checked
A check has a defined scope and environment. A good result for one component does not establish every integration, every device or the security of a whole product.
What remains open
When evidence is missing, we say what we do not know. A hypothesis, a product idea and a measured result remain different things.
A repair needs a check
For a software problem, we establish the intended behaviour, reproduce the defect, make a precise change and check the result. The tested scope and its limitations stay with the conclusion.
An available product has a clear destination
A public project identifies what you can use and where. Work in development explains what exists and what is missing. Demonstrations and archived records do not promise the state of a current service.
Data and security
For information about data sent through this site, see privacy. For a security concern, contact the designated lead.