#Byte count should be based on the file

Regardless of what "header" or "boilerplate" is included, you need to be able to save your source code to a file in some manner for it to qualify, and your score in bytes is the size of that source code in bytes. If you find or make some alternative way to store your TPT programs as a file, and provide an interpreter which can read those files and run the program they represent, then that file format is an option for scoring. A similar situation happened with Minecraft, and the consensus was that there had to be an actual file to use as the byte count, but scores were later greatly improved when a more efficient way of storing structures as files was added. Fortunately you mostly compete within a language rather than between languages because the numbers just differ so much, so as long as the file size correlates reasonably well with program complexity (so golfing remains a programming challenge rather than just an optimize stuff for the file format challenge) it won't really be a problem in my mind. If the file size does not correlate well with complexity... sorry, but you still need to be able to store your source code in a file.

###Output

All of the output formats you listed seem appropriate, though I can't evaluate them for sure without more information. As long as you can explain how someone runs the program and how they obtain the output it's probably fine and in some narrow situations it could even be legitimate to use multiple output types in a single answer

###Input

For languages that don't accept a standardized or simple Input mechanism, deciding how input is obtained is dependent on relatively deep knowledge of that specific language that I just don't have. In general though, a good input method should be easy to adapt to any challenge. As an example, a language with memory represented as an infinite list of Stacks and no input functionality would most likely take input by assuming the first stack starts populated with the entire input. An uncommon alternative might be that stacks starting from the first and extending to the right each have exactly one item of the input. It would not be allowed to determine for each challenge that it wants, say, "the first input stored in the third stack, the second and third both on the seventh stack, and the fourth input stored as a negative value underneath three 0s in the eleventh stack" and just have input data always prepopulated wherever is convenient.

###Is it a language?

If TPT can truly be used to construct functional computers as you claim, then it almost certainly is enough of a programming language for us. The requirements are not very strict.

##Suggestion

Try posting an answer to one of the basic challenges like Add two numbers or "Hello, World!" and we can give more definitive comments. I'd recommend Add two numbers so we can critique input methods as well. As long as you're reasonably responsive to comments it shouldn't be deleted and can serve as valuable precedent for future decisions.

Byte count should be based on the file

Regardless of what "header" or "boilerplate" is included, you need to be able to save your source code to a file in some manner for it to qualify, and your score in bytes is the size of that source code in bytes. If you find or make some alternative way to store your TPT programs as a file, and provide an interpreter which can read those files and run the program they represent, then that file format is an option for scoring. A similar situation happened with Minecraft, and the consensus was that there had to be an actual file to use as the byte count, but scores were later greatly improved when a more efficient way of storing structures as files was added. Fortunately you mostly compete within a language rather than between languages because the numbers just differ so much, so as long as the file size correlates reasonably well with program complexity (so golfing remains a programming challenge rather than just an optimize stuff for the file format challenge) it won't really be a problem in my mind. If the file size does not correlate well with complexity... sorry, but you still need to be able to store your source code in a file.

Output

All of the output formats you listed seem appropriate, though I can't evaluate them for sure without more information. As long as you can explain how someone runs the program and how they obtain the output it's probably fine and in some narrow situations it could even be legitimate to use multiple output types in a single answer

Input

For languages that don't accept a standardized or simple Input mechanism, deciding how input is obtained is dependent on relatively deep knowledge of that specific language that I just don't have. In general though, a good input method should be easy to adapt to any challenge. As an example, a language with memory represented as an infinite list of Stacks and no input functionality would most likely take input by assuming the first stack starts populated with the entire input. An uncommon alternative might be that stacks starting from the first and extending to the right each have exactly one item of the input. It would not be allowed to determine for each challenge that it wants, say, "the first input stored in the third stack, the second and third both on the seventh stack, and the fourth input stored as a negative value underneath three 0s in the eleventh stack" and just have input data always prepopulated wherever is convenient.

Is it a language?

If TPT can truly be used to construct functional computers as you claim, then it almost certainly is enough of a programming language for us. The requirements are not very strict.

Suggestion

Try posting an answer to one of the basic challenges like Add two numbers or "Hello, World!" and we can give more definitive comments. I'd recommend Add two numbers so we can critique input methods as well. As long as you're reasonably responsive to comments it shouldn't be deleted and can serve as valuable precedent for future decisions.